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

[jnemeth%victoria.tc.ca@localhost (John Nemeth)]

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).

}-- End of excerpt from Marc Balmer