[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: lua(4), non-invasive and invasive parts
> 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
Main Index |
Thread Index |