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

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

Brian,

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

Yes, it should be possible to write a line discipline in such a way that the 
existing line discipiline code (or rather those parts of the tty subsystem that 
actually call the line disciplines routines) don't need to be touched.

As for not being fluent in Lua, it's a fairly easy language with some very nice 
aspects (closures, easy sandboxing, easy integration, small memory footprint, 
among others).

For review and comments I uploaded the current state of lua(4) to the following 
location:
http://www.netbsd.org/~mbalmer/diffs/

(The diff is numbered, starting at kernel_lua_010.diff, I will increase the 
number as the diff further evolves)

- Marc