18.10.2013, в 21:03, John Nemeth <jnem...@cue.bc.ca> написал(а):
> 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. Probably. It should be named as 'auto assign' for clarity, as module loading occurs anyway. > 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. This is exactly what lua(4) does on 'requiring'. > 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. kern.lua.autoload is a safety barrier. One may wish not allow any lua kernel script to load any given lua kernel module. > > } > [1] https://github.com/orangeduck/LuaAutoC > } > }-- End of excerpt from Marc Balmer -- dukzcry