Re: Lua in-kernel (lbuf library)

[Artem Falcon <lomka%gero.in@localhost>]

Marc Balmer <marc <at> msys.ch> writes:
> >> Justin Cormack <justin <at> specialbusservice.com> writes:
> >> I have been using the luajit ffi and luaffi, which let you directly
> >> use C structs (with bitfields) in Lua to do this. It makes it easier
> >> to reuse stuff that is already defined in C. (luaffi is not in its
> >> current state portable but my plan is to strip out the non portable
> >> bits, which are the function call support).
> >>
> >> Justin

I had successfully used more lightweight solution called "Lua AutoC" [1] with
Marc's lua(4).
Pros: light in comparison to other FFI libs, joy in use, easy to adopt to be
used in kernel, does the things in runtime, which gives the flexibility.
Cons: not widely tested, again does the things in runtime, which on other
side may give performance penalty.

> > 
> > I never used luaffi. It sounds very interesting and I think it could
> > be very useful to bind already defined C structs, but my purpose is to
> > dynamically define data layouts using Lua syntax (without parsing C
> > code).
> 
> FFI in the kernel can be dangerous.  Pure Lua is a perfect confinment
> for code, but with an FFI a Lua script can access almost anything in the
> kernel.  One has to think twice if one wants that.
> 
> Well, assuming it would be module, so I would not have to load it if I
> don't want to.

It's desirable if you're writing a device driver in Lua, as you can do
most of work from Lua code (e.g. call C methods of NetBSD driver API
and feed them with C structs and pointers).
States and explicit exports of a certain foreign functions makes things
a bit less dangerous.
But in general you're right, one should do this with care.

[1] https://github.com/orangeduck/LuaAutoC