6lowpan next header compression framwork: module handling or not?

6lowpan next header compression framwork: module handling or not?

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

Re: 6lowpan next header compression framwork: module handling or not?

[Jukka Rissanen]

Hi Alex,

On pe, 2014-12-05 at 13:46 +0100, Alexander Aring wrote:
> 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_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.

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.

> 
> 
> What should I do now?
> 
> - Alex


Cheers,
Jukka

Re: 6lowpan next header compression framwork: module handling or not?

[Alexander Aring]

Hi Jukka,

On Fri, Dec 05, 2014 at 03:42:06PM +0200, Jukka Rissanen wrote:
...
> 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

Re: 6lowpan next header compression framwork: module handling or not?

[Jukka Rissanen]

Hi Alex,

On pe, 2014-12-05 at 15:31 +0100, Alexander Aring wrote:
> Hi Jukka,
> 
> On Fri, Dec 05, 2014 at 03:42:06PM +0200, Jukka Rissanen wrote:
> ...
> > 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.
> 

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


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