Am 28.12.2012 um 12:19 schrieb John Nemeth <[email protected]>:
> On May 20, 6:34am, Marc Balmer wrote: > } Am 28.12.2012 um 11:43 schrieb Jukka Ruohonen <[email protected]>: > } > On Fri, Dec 28, 2012 at 11:35:05AM +0100, Marc Balmer wrote: > } >>> What does this mean? Also the kernel modules using lua(4) will be > } >>> conditionally compiled? I think this is fairly strongly against the > design > } >>> principles of module(7). > } >> > } >> This means that gpiosim(4) can be compiled with Lua support, if 'options > } >> LUA' is defined in the kernel configuration. As Lua in the kernel is > } >> experimental, such a guard makes sense. > } > > } > I think this has been discussed previously, the conclusion being that > kernel > } > modules should not diverge upon changes in the kernel configuration > options. > } > > } > The practical case is: what happens when I try to load gpiosim(4) after > } > having compiled a kernel with a LUA option but not having updated > } > userland/modules (or vice versa)? > } > } No harm done. > } > } A gpiosim(4) module compiled without lua(4) support will just work (if > } gpio(4) support is present), a gpiosim(4) module compiled *with* lua(4) > } support will try to load the gpio(4) module and the lua(4) module, and > } if either fails it will itself not load. > > The point is that module compilation is in no way dependent on the > kernel config file (at the moment). This means that putting > "options LUA" in a kernel config file will not change how the gpiosim > module is compiled. As a result the gpiosim module should always be > compiled as if "options LUA" was defined (once the lua module exists, > of course). Oh, yes, that is a good point. So I think the best is t forget about 'options LUA' for now.
