tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Lua in-kernel (lbuf library)



Am 18.10.13 10:43, schrieb Artem Falcon:
> 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.

lua(4) has a mechanism for Lua's 'require' statement.  Normally, when
you require 'foo', it looks up wheter a kernel module name luafoo exists
and loads it.  This automatic loading of modules can be turned off, to
make a module available to a state, it has to be specifically assigned.
 So when you turn autoloading off, a script could not simply call a ffi
module by requiring it.

Maybe Lua kernel modules should carry a flag whether they should allow
autoloading or not?  This way, an ffi module would still be loaded into
the kernel when Lua code requires it, but lua(4) would detect the "don't
autoload" flag and would then not_ assign the module to the Lua state.

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



Home | Main Index | Thread Index | Old Index