[OE-core] [PATCH] kernel-module-split: Add support for KERNEL_MODULE_AUTOLOAD and KERNEL_MODULE_PROBECONF
Denys Dmytriyenko
denis at denix.org
Mon Jun 23 22:54:57 UTC 2014
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
>
More information about the Openembedded-core
mailing list