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

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

        Hello.  I'm not going to call myself an expert on such things, but it
seems like a better design would be to write a module that acts as a bridge
to the lua environment.  That is, write a lua function that actually maps
to the tty functions you want to access in the kernel and then calls those
using the c calling conventions. So, for example, if you want to use the
ttyioctl functions in lua to set the line discipline, write a function that
looks like the ttyioctl function in lua, which, in turn, calls the c
equivalent in the kernel. Locate this lua library in the same place you put
the lua code that's "non-invasive".  I'm not fluent in lua, but there must
be a precedent for this sort of thing.  For example, how do user-land lua
programs make system calls currently?  How do they access libc(3)
functions?  This approach seems like it gives you 2 things: better
longevity as the internals of the kernel change, as long as you use
long-standing documented interfaces, and code maintainability.  As Lua
changes, it can be updated with little fear of breaking something in the
kernel.  those, to me, seem like big wins.  Just my 2 cents.
-Brian

On Dec 24, 10:49am, Marc Balmer wrote:
} Subject: 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.
} >=20
} > 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.
} >=20
} > 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.=
>-- End of excerpt from Marc Balmer