[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Lua in-kernel (lbuf library)
On Oct 19, 12:13am, Artem Falcon wrote:
} 18.10.2013, × 21:03, John Nemeth <jnemeth%cue.bc.ca@localhost> wrote:
} > 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"
} > } > Marc's lua(4).
} > } > Pros: light in comparison to other FFI libs, joy in use, easy to adopt
} > } > used in kernel, does the things in runtime, which gives the flexibility.
} > } > Cons: not widely tested, again does the things in runtime, which on
} > } > 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
} > } >> 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 noautoload 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.
The lua(4) implementers can certainly do this if they want.
However, module_autoload() won't be looking at this flag and will
continue to refuse to autoload any module that has the noautoload
flag set. Also, there is the kern.module.autoload sysctl that can
prevent any module from autoloading.
}-- End of excerpt from Artem Falcon
Main Index |
Thread Index |