Re: lua(4), non-invasive and invasive parts

[Marc Balmer <marc%msys.ch@localhost>]

Am 28.12.2012 um 12:19 schrieb John Nemeth <jnemeth%victoria.tc.ca@localhost>:

> On May 20,  6:34am, Marc Balmer wrote:
> } Am 28.12.2012 um 11:43 schrieb Jukka Ruohonen <jruohonen%iki.fi@localhost>:
> } > 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.