Hi Jukka, On Tue, Sep 02, 2014 at 09:08:10AM +0300, Jukka Rissanen wrote: > Hi Alex, > > On ma, 2014-09-01 at 13:38 +0200, Alexander Aring wrote: > > Hi, > > > > On Mon, Sep 01, 2014 at 01:36:14PM +0300, Jukka Rissanen wrote: > > > Hi Alex, > > > > > > I saw your RFC mail (9 Aug) about generic compression layer. Was there > > > any functionality changes by this RFC or was it just refactoring the > > > code? > > > > > > > It's not just refactoring. The point is that there are many of RFC's > > outside which declare a next header compession format (like UDP). UDP is > > the only one next header compression which we currenlty support. If we > > don't add a layer to add a new header compression format, all people > > hack this into the iphc.c file. I don't know what you think about this > > but I really don't like that. > > > > This code adds a layer for this and supports all other known next header > > compression formats in the way that we drop the packets afterwards > > instead of deliver garabage to next layer (IPv6). > > > > The layer avoids that everybody hacks static code into iphc file. > > Ok, sounds like a plan. > > > > > Please let me know if this is okay for you, then I will send a v2 with > > changes. > > Sure, just send new version. > ok. > > > > > Anyway, looks ok to me although I just browsed quickly through the code, > > > did not really review it :) Just wondering do we need more > > > subdirectories under 6lowpan or could we just put everything into > > > 6lowpan dir (just to keep it simple)? No big preference here thou. > > > > > > > Don't know, but there is a unkown number of possible next header compression > > formats outside, we should split it in a new subdirectorie. What I > > actually mean, don't hack every next header compression format in a > > single file. > > I was not really thinking that all the stuff would be in single file. I > was just pondering is there really a need for sub-directory, after all > the number of files in net/6lowpan directory is currently very small so > one option could be to put the nhc files directly into 6lowpan directory > (and perhaps adding them nhc_ prefix). Anyway, this is minor thing and I > am fine with having sub-directories. > ok. I that was the behaviour in one of my first series. I will change it according to that. I agree with you here. > > > > For address compression/uncompression this is fine, there is no unknown > > numbers of compression ways. > > > > I know only IPHC and HC1. HC1 should be support for receiving side and > > it's obsolete, but this is rfc 4944 so it's only related to 802.15.4. > > > > Some or later we need to add support for this, but this should not used > > by bluetooth 6LoWPAN. > > > > > I saw the mail from Varka Bhadram (6 Aug) about RFC 6775 support. That > > > looked interesting. Did you get the code from him (if yes, could you > > > also send it to me)? Do you know why this guy have not send this stuff > > > to upstream? > > > > > > > The 802.15.4 mac layer has some neighbor discovery issues which are not > > solved currently. It's about two kinds of mac addresses, for bluetooth > > it should be fine. A small description about this problem is here [1]. > > > > We need some way to trigger 6LoWPAN/Layer 2 data across the IPv6 layer > > and this isn't easy. Everything what we do on runtime decisions makes > > the IPv6 stack slower and we should avoid that. > > Yep, agreed. > That's the big challenge to make an acceptable mainline solution. :-) At the end it should be acked by IPv6 community, they should scream if a solution makes runtime decisions which slower down the stack too much. > > > > > > > > I currently working on a big rework of the 802.15.4 layer and will try > > to bring this mainline at end of this month. Our mac layer is currenlty > > in an not useable state. :( > > > > I don't have time to make some effort after IPv6, currently I work on > > the rework and will solve the two kind mac addresses issues with the > > neighbor discovery cache, then we are in some state which we don't have > > some broken support of functionality. > > > > > > Maybe simple talk with Varka about what he did there, because I don't > > really know what he exactly did there. The code what I saw isn't > > mainline able. [0] What I know that RFC 6775 and the actually > > implementation need to handle the two kinds of mac addresses (which is > > broken currenlty) and need support of context based address compression. > > > > I don't have time to add support for this. I need to rescue the 802.15.4 > > layer. Sorry! Maybe after that... or maybe somebody will do this work. > > It sounds for me crazy to support RFC6775 which has dependencies on > > other functionality which we doesn't support right now. For bluetooth > > the mac layer works great, we only needs support for context based > > address compression then. > > Ok. Currently I am also busy with some other stuff but I try to find > some time to investigate the RFC6775 more. Cannot really promise any > dates etc. > Ok, null problem. - Alex -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
