On Mon, Jun 23, 2014 at 06:54:57PM -0400, Denys Dmytriyenko wrote: > 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.
Sometimes basename != module name and having multiple entries in one /etc/modules-load.d/file is sometimes useful, see http://lists.openembedded.org/pipermail/openembedded-core/2014-July/094645.html which returns support for both features > > > 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 > > > -- > _______________________________________________ > Openembedded-core mailing list > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: [email protected]
signature.asc
Description: Digital signature
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
