Re: Lua in-kernel (lbuf library)

[Artem Falcon <lomka%gero.in@localhost>]

18.10.2013, в 21:03, 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.

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