Re: [PATCH v2 bluetooth-next 0/7] GHC compression detection

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

On Wed, Nov 25, 2015 at 03:59:10PM +0100, Stefan Schmidt wrote:
> Hello.
> 
> This is a first stab at RFC7400. So far we only hook into the NHC framework to
> detect the registered GHC types (extension headers, UDP and ICMPv6).
> This is aligned with how we detect the NHC frames.
> 

TODO for next is to make possible that we can load multiple nhc modules
for the transmit side. We have a 1(tranmit):n(receive) mapping here, and
we should support all nhc's for receive side.

For tranmsmit side we should have a disable by default and offer a
debugfs entry (nhc framework debugfs support) to enable/disable it
at runtime. It's a 1:nexhdr mapping, so only one for nexthdr can running
at the same time currently. If somebody tries that it should be return
-EBUSY.

I would suggest additional patches:

1. Allow to have register everything and disable compression methods of
   all nhcs by default. The receive handling should always possible,
   the compression should be disabled by default because other 6LoWPAN
   stacks may not support e.g. GHC types.

   Maybe we can do a nhc directory for the debugfs interface related entry
   for that. So the nhc framework offers some support e.g. enable compression
   for nhc xy.

2. Add all you nhc's _after_ all other nhc modules. This will occur that
   the first ones has a higher priority. Our priority strategy is then
   like the order of the list. See [0].

3. Add "default y" to all nhc's for support receiving always.


That's huge work, but maybe the next steps.

Otherwise it's looking good and let the NHC framework as first known
about these next header compressions, so:

Acked-by: Alexander Aring <alex.aring@gmail.com>

- Alex

[0] http://lxr.free-electrons.com/source/net/6lowpan/core.c#L24