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

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

> A good part of Lua in the kernel is non-invasive, i.e. it consists of 
> software that you can use or not.  These parts, namely the lua(4) device 
> driver, the Lua kernel modules that provide Lua bindings to the kernel, and 
> the luactl(8) utility, are non-critical since they are "stand-alone" without 
> needing any other sources to be changed.
> 
> There are, however, more invasive parts:  When an existing piece of software 
> want's to make use of Lua, these parts need to be made Lua-aware.  This means 
> changing, or rather extending, the source code.  Think e.g. about the tty 
> line disciplines which could be modified to allow for line disciplines to be 
> written in Lua.  The line disciplines code needs to create a Lua state for 
> that, Lua code has to be loaded, and finally the tty line disciplines 
> "subsystem" must call into the Lua code.
> 
> For such more invasive changes, I foresee to use a kernel option, 'options 
> LUA' which will compile such code only when the option is enabled.  It will 
> be commented out by default, besides maybe the ALL kernels.

I forgot to mention that the vast majority of the Lua in kernel software is 
actually of the non-invasive nature.  Line disciplines are actually the only 
area where I will try to use Lua (because I have a need for it), and that part 
will only go in if it is useful.  But I think is important to already have some 
guidelines on how to integrate Lua, just in case someone wants to do that with 
his/her code.