Re: [PATCH] kernel-module-split: Add support for KERNEL_MODULE_AUTOLOAD and KERNEL_MODULE_PROBECONF

[Denys Dmytriyenko <denis@denix.org>]

Sorry for the delay...

On Tue, Jun 17, 2014 at 05:46:58PM +0100, Richard Purdie wrote:
> On Tue, 2014-06-17 at 14:53 +0000, Hart, Darren wrote:
> > Adding Scott R.
> 
> I do need to sort out a documentation update.
> 
> > I was just looking into that. It appears the ref-manual.html is the place
> > to update. The glossary has a module_autoload definition, which I suppose
> > needs to be replaced with KERNEL_MODULE_AUTOLOAD, which  will have
> > slightly different semantics.
> > 
> > If I understand this correctly, the old model was:
> > 
> > 	module_autoload_foo = "foo"
> > 	module_autoload_bar = "bar"
> > 
> > Although the following line in the docs confuses me:
> > 
> > 	module_autoload_<modname> = "modname1 modname2 modname3"
> 
> That is just wrong.

Yeah, I think I confused people here... During one of the discussions I tried 
to mention that standard /etc/modules-load.d/ can have a single file with 
multiple module entries in it (and the above line was given as an example). 
Unfortunately, kernel-module-split class couldn't handle that and required 
placing one module entry per file. So the old syntax would look like this:

module_autoload_<modname1> = "modname1"
module_autoload_<modname2> = "modname2"
etc.

Sorry for the confusion.


> > And now, if I interpreted the commit comment correctly, it should look
> > like:
> > 
> > 	KERNEL_MODULE_AUTOLOAD = "foo"
> > 	...
> > 	KERNEL_MODULE_AUTOLOAD += "bar"
> 
> Correct.
> 
> > I'm not sure how KERNEL_MODULE_PROBECONF is involved, or what value it
> > brings beyond module_conf. From what I can tell, the changes now require:
> > 
> > 	KERNEL_MODULE_PROBECONF = "foo"
> > 
> > 	module_conf_foo = "options foo baz=1"
> > 
> > (/me notes the order of operations is non-obvious here "if modconf and
> > basename in modconflist")
> 
> For module_conf, the value is the build system can know which variables
> were set and account for them in the task checksums. If it doesn't have
> the list, we'd have to iterate the whole data store and that is a
> *painfully* slow operation.
> 
> module_conf isn't commonly used so maintaining a list isn't too much of
> a hardship IMO.
> 
> > Do I have this correct?
> 
> Yes.
> 
> CHeers,
> 
> Richard
>