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

[Alexander Aring <alex.aring@gmail.com>]

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.

- Alex