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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


--
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



[Index of Archives]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux