[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: lua(4), non-invasive and invasive parts
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
> } >>> 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
> } > modules should not diverge upon changes in the kernel configuration
> } >
> } > 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.
Main Index |
Thread Index |