Re: Lua in-kernel (lbuf library)

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Oct 18, 11:03am, Marc Balmer wrote:
} 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.

     There is already a mechanism for this, see module_autoload(9).
You should always be using module_autoload() to load a module from
inside the kernel.  If the no autoload flag is set, then the call
will fail.  Thus, there is no need for lua(4) to try managing this
itself.  It should just attempt to load the module.  If successful,
great.  If not, then the feature being requested isn't available.

} > [1] https://github.com/orangeduck/LuaAutoC
} 
}-- End of excerpt from Marc Balmer