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