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@xxxxxxxxx> - Alex [0] http://lxr.free-electrons.com/source/net/6lowpan/core.c#L24 -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
