Re: [PATCHv4 bluetooth-next 0/3] 6lowpan: introduce nhc framework

[Stefan Schmidt <s.schmidt@samsung.com>]

Hello.

On 08/01/15 21:08, Alexander Aring wrote:
> On Thu, Jan 08, 2015 at 09:04:43PM +0100, 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].
>>
>> 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).
>>
>> 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?
>>
>
> We can also put all udp compression formats into the nhc_udp.c file. But
> then all udp compressions are handled by one module then. We should not
> do that, because we can handle it per module.

I would keep them all in different modules for now.

regards
Stefan Schmidt