6lowpan next header compression framwork: module handling or not?
Subsystems (2)
Alexander Aring
maintainerHi,
last patch series Jukka, told me to make default "loading" of some next header compression formats. I agree with that, so users don't need to extra loading some next header compression modules.
Per default we support some compression formats, that sounds good.
Before that Marcel told (I think if I understand it right) that he wants to have each nhc compression as separate module and users can do some modalias magic for autoloading.
Currently I see no option to add support for both of them.
If I do Jukka's default "loading" (not loading of module) I add nhc and all compression layers into the 6lowpan.ko module. While module_init of 6lowpan.ko we add all default nhc's. On module_exit we remove _all_ registered nhc.
Marcel idea with modules we have in each nhc compression format a module_init and a module_exit function. In these functions the nhc compression format will be added to the nhc framework and removed. With this solution I can't implement some "load all defaults nhc modules, while loading 6lowpan.ko module. Users need to do some configuration to make this default available at startup.
What should I do now?
- Alex
Hi Alex,
Quoted 20 lines · Alexander Aring
Hi,
last patch series Jukka, told me to make default "loading" of some next header compression formats. I agree with that, so users don't need to extra loading some next header compression modules.
Per default we support some compression formats, that sounds good.
Before that Marcel told (I think if I understand it right) that he wants to have each nhc compression as separate module and users can do some modalias magic for autoloading.
Currently I see no option to add support for both of them.
If I do Jukka's default "loading" (not loading of module) I add nhc and all compression layers into the 6lowpan.ko module. While
module_initof 6lowpan.ko we add all default nhc's. Onmodule_exitwe remove _all_ registered nhc.
Quoted 6 lines
Marcel idea with modules we have in each nhc compression format a
module_initand amodule_exitfunction. In these functions the nhc compression format will be added to the nhc framework and removed. With this solution I can't implement some "load all defaults nhc modules, while loading 6lowpan.ko module. Users need to do some configuration to make this default available at startup.
If there would be a "default" module that gets automatically loaded if no other module is used / configured, then both of these wished would be full filled.
So my point was that the current way of compressing things i.e., the "default" would be used if no other compression method is found/configured (I probably expressed myself poorly in my previous mail ;)
I am fine if the "default" being a module, as long as it is automatically loaded. From the end user point of view, he/she should not configure or do any magic in order to use 6lowpan.
Quoted 5 lines
What should I do now?
- Alex
Cheers,
Jukka
Alexander Aring
maintainerHi Jukka,
On Fri, Dec 05, 2014 at 03:42:06PM +0200, Jukka Rissanen wrote:
...
Quoted 4 lines
I am fine if the "default" being a module, as long as it is automatically loaded. From the end user point of view, he/she should not configure or do any magic in order to use 6lowpan.
Seems that I am not a module linux guru. I don't know how I can implement such feature. The nhc compression module depends on 6lowpan.ko module but 6lowpan.ko can't depend on the nhc compression modules. If there would be some dependency then 6lowpan.ko would load the compression modules at module_init. Means some symbols are missing and "something" try to load the right modules to get these symbols.
I tried to create such behaviour but failed. I don't know if this is really possible or I don't know how I can implement this behaviour.
What I tried was to implement a "dummy" function, which seems to be also a hack in my opnion. This "dummy" function was implemented in the nhc module.
void lowpan_nhc_rfc6282_udp_load(void) { }EXPORT_SYMBOL(lowpan_nhc_rfc6282_udp_load);
Then lowpan_nhc_rfc6282_udp_load was called at module_init of 6lowpan.ko but I got some linking issues.
Maybe I need some time to getting the idea how I can implement such behaviour without ugly hacks. Currently I don't know how I can implement something like that. Maybe the solution is easy.
- Alex
Hi Alex,
Quoted 19 lines · Alexander Aring
Hi Jukka,
On Fri, Dec 05, 2014 at 03:42:06PM +0200, Jukka Rissanen wrote:
...Quoted 4 lines
I am fine if the "default" being a module, as long as it is automatically loaded. From the end user point of view, he/she should not configure or do any magic in order to use 6lowpan.
Seems that I am not a module linux guru. I don't know how I can implement such feature. The nhc compression module depends on 6lowpan.ko module but 6lowpan.ko can't depend on the nhc compression modules. If there would be some dependency then 6lowpan.ko would load the compression modules at
module_init. Means some symbols are missing and "something" try to load the right modules to get these symbols.I tried to create such behaviour but failed. I don't know if this is really possible or I don't know how I can implement this behaviour.
Quoted 9 lines
What I tried was to implement a "dummy" function, which seems to be also a hack in my opnion. This "dummy" function was implemented in the nhc module.
void
lowpan_nhc_rfc6282_udp_load(void){ }EXPORT_SYMBOL(lowpan_nhc_rfc6282_udp_load);Then
lowpan_nhc_rfc6282_udp_loadwas called atmodule_initof 6lowpan.ko but I got some linking issues.
I am not an expert on kernel modules but perhaps one option could be the request_module() function that can load the desired module.
http://lxr.free-electrons.com/source/kernel/kmod.c#L118
Quoted 6 lines
Maybe I need some time to getting the idea how I can implement such behaviour without ugly hacks. Currently I don't know how I can implement something like that. Maybe the solution is easy.
- Alex
Cheers,
Jukka