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