Hi, On Fri, Jan 09, 2015 at 01:05:22PM +0000, Stefan Schmidt wrote: > Hello. > > On 08/01/15 21:04, Alexander Aring wrote: > >Hi, > > > >On Thu, Jan 08, 2015 at 07:18:57PM +0000, Stefan Schmidt wrote: > >... > >>>>net/6lowpan/nhc.h | 146 ++++++++++++++++++++++++ > >>>>net/6lowpan/nhc_rfc6282_dest.c | 27 +++++ > >>>>net/6lowpan/nhc_rfc6282_frag.c | 26 +++++ > >>>>net/6lowpan/nhc_rfc6282_hop.c | 26 +++++ > >>>>net/6lowpan/nhc_rfc6282_ipv6.c | 26 +++++ > >>>>net/6lowpan/nhc_rfc6282_mobil.c | 26 +++++ > >>>>net/6lowpan/nhc_rfc6282_route.c | 26 +++++ > >>>>net/6lowpan/nhc_rfc6282_udp.c | 156 ++++++++++++++++++++++++++ > >>> > >>>can we please remove the _rfc6282 from the filenames. RFCs get update and > >>>thus change numbers. I do not want to carry RFC numbers in filenames > >>>around. There is also almost no precedence in the kernel source code that > >>>would justify doing this. > >> > >>They look indeed quite ugly in the filename. :) > >> > >>Moving them as a comment and starting point into the file should be > >>enough. > >>Maybe we can also rename nhc_mobil to nhc_mobility. The other > >>abbreviations > >>are clear in my opinion but for mobil I actually opened the rfc to look > >>what > >>you mean here. > >> > > > >For the rfc6282 thing: > > > >Currently there exists two RFCs which describes an UDP compression. It's > >rfc6282 (the well known 6LoWPAN IPHC compression RFC) and RFC7400 which > >was pointed out by Martin Townsend [0]. > > November 2014, thats really new. > > >We need to clarify how we should deal with multiple definitions for a > >compression format. On receiving side we should always support what we > >can which is decided by the variable nhcid length. While on transmit... > >we need still some configuration interface (my dreams are to decide the > >compression methods per socket, don't know how possible that is). > > As a general rule we should try to accept, identify and uncompress as many > formats for the incoming side. For the sending side this decision is very > unlikely to be made by the application but instead it is made by the system > configurator / platform. Thus in my eyes it makes more sense to have the > configure options either via netlink or sysfs but not over the socket > interface. > yes, this is the next part which is also more easier than the per socket interface. To make this just per socket is more granularity than have a "global setting" for this. Maybe we can handle this in one net namespace configuration, but this also seems after the a step to introduce a netlink configuration framework. I already talked with Jukka and he also agree For a netlink interface (this was in some previous series). > >For the handling I thought that we have then two UDP nhc modules, both > >can be loaded (at the moment _only_ one UDP nhc compressression should > >implement the compress methods, both should implement uncompression > >methods). > > > >I can rename it to nhc_udp.c for the standard compression methods > >according to rfc6282, I am fine with that. But later there exists then > >an another compression module with the naming "nhc_ghc_udp.c" or > >something else. So we have "nhc_udp.ko" and "nhc_ghc_udp.ko". > >Is that okay for everybody? > > It would be ok for me. nhc_udp is the earlier spec and thus has a shorter > name while we need to distinguish for later specs and add the ghc for it. In > a later mail you mentioned using _iphc_ and _ghc_ I would avoid that because > GHC is just plugged into NHC and thus is also a under the IPHC umbrella of > compressions. :) > ok. > >Maybe I should also add some modinfo information, which containing the > >nhc->name. > > Maybe. For what would it be used? Having a human readable description would > make sense for the configure interface in some cases I would say. > For `modinfo $NHC_MODULE`. > >For the nexthdr names: > > > >I will try to change it according to the NEXTHDR IPv6 defines [1], so also > >the linux IPv6 guys knows what it is. > > That looks good to me. > ok. - 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
