[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Lua in-kernel (lbuf library)
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"  with
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.
Main Index |
Thread Index |