Re: Lua in-kernel (lbuf library)
On Tue, Oct 15, 2013 at 06:01:29PM -0300, Lourival Vieira Neto wrote: Also, having to switch mentally between zero-based arrays in the kernel C code and 1-based arrays in the Lua code make my head ache. Above this well-discussed inconvenience there is a thing which may hurt more. It's the Lua's stack-based C API and all the stack composition pottering it imposes on you. This may be customary for those having an experience with concatenative languages, but it'll be a source of errors for the others. See [1]'s Stack based API is harder for more on it. [1] http://julien.danjou.info/blog/2011/why-not-lua -- dukzcry
Re: Moving Lua source codes
2013/10/21 Marc Balmer m...@msys.ch: Am 20.10.13 22:02, schrieb Artem Falcon: [...] Ok, here i have a clean diff. Sorry for the attach instead of inline. By the way, do you want to move from malloc(9) to kmem(9) as recommended? I may provide a draft version, if you're interested. Thank you for your diff, I will look at it in a few days (I am not at my office the next few days, being abroad for @work stuff). As for malloc(9) switching to kmem(9), I don't want to do that because of the way how Lua allocates memory. An allocator function is called with some number of bytes to be allocated. We have no control over how many bytes it wants us to allocate. If using kmem(9), we would have to keep track of this allocations, since kmem_free() takes as a second argument the number of bytes to free. kmem(9) is not very usable here imo, since we have to pass the number of bytes to free. Now i see. Thanks for clearing it out. btw, you can also CC tech-kern@, no need to keep this discussion private... Doing w/o a diff, i don't have a sane mail environment now to send it inline. There's few more things. First: you forgot to add MODULE_CLASS_LUA_BINDING to a sys/sys/module.h. Second: kernel side Lua will reject to load bytecode produced by luac cause the first built FPless. A simple solution is to build luac and liblua feeded with FPless luaconf.h and put them under different names. Maybe a more elegant solution is possible?
Re: Lua in-kernel (lbuf library)
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
Re: Moving Lua source codes
Mouse mouse at Rodents-Montreal.ORG writes: ... I think the biggest reasons I haven't tried to push any of those into NetBSD are (1) a perception that NetBSD doesn't want my changes, combined with (2) a lack of motivation to, a sort of NetBSD no longer cares about me; why should I care about it? feeling. (Note that I'm not saying anything about how justifiable - or correct! - these feelings are.) That said I'd certainly be happy to offer any-to-all of my changes to anyone who wants to bring them into NetBSD. ... If anyone's interested, of course. My expectation has been that nobody is, but this email makes me think that could well be wrong. I can easily pull a full list of changes I've made and mail it wherever. Mouse, I'm not an EdgeBSD advocacy, but when i've heard of it and briefly looked at i got a feeling that they're kinda open to bringing of various experimental things, even kernel-side ones. I don't know their relations with NetBSD project, but there was an info that they will try to push well-tried bits back to the NetBSD. If all of this is true, maybe it's a more suitable place for your stuff now?
Re: Lua in-kernel (lbuf library)
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. [1] https://github.com/orangeduck/LuaAutoC
Re: Lua in-kernel (lbuf library)
Lourival Vieira Neto lourival.neto at gmail.com writes: On Wed, Oct 16, 2013 at 11:45 AM, Justin Cormack justin at specialbusservice.com wrote: (...) Yes absolutely it makes more sense if already defined in C. For parsing binary stuff I would look at Erlang for inspiration too, it is one of the nicer designs. Justin I never gone that far in Erlang. It looks really interesting [1]. I'll take a deeper look later. Thanks! Regards, I think a hybrid approach with mutable C-like data structs for holding of binary data and Erlang's binary pattern matching would be cool. -- dukzcry
Re: Moving Lua source codes
Marc Balmer marc at msys.ch writes: Hi All I am in the progress of ... - Commiting the kernel parts from our GSoC project, Lua in the NetBSD Kernel ... - mbalmer Hi, Marc Had you managed to fix broken things i mentioned here? [1] Thank you! [1] http://marc.info/?l=netbsd-tech-kernm=137111030727302w=2
Re: Importing lua(4), but where in the source tree?
Marc Balmer marc at msys.ch writes: Sure. The full diff is at http://www.netbsd.org/~mbalmer/diffs/kernel_lua_010.diff and it's the files that the diff now places in sys/modules/lua/ that I think should better go to sys/dev/lua/ Marc, Very nice work! However, i've found few problems in the code, which i've tried to eliminate. See: https://github.com/druga/netbsd-lua/tree/master/sys/modules/lua Sorry for not producing the clean diff. I didn't make it, since more changes may follow. As for now, the commit history [1] should provide the changes i've done for all of the problems except the 1.-st one. Note that 4.-th issue is critical and 3.-rd is serious. This first one leads to a trap on lua modules loading after destroying of some state. [1] https://github.com/druga/netbsd-lua/commits/master/sys/modules/lua/lua.c -- dukzcry
Re: Importing lua(4), but where in the source tree?
Marc Balmer marc at msys.ch writes: Sure. The full diff is at http://www.netbsd.org/~mbalmer/diffs/kernel_lua_010.diff and it's the files that the diff now places in sys/modules/lua/ that I think should better go to sys/dev/lua/ Marc, Very nice work! However, i've found few problems in the code, which i've tried to eliminate. See: https://github.com/druga/netbsd-lua/tree/master/sys/modules/lua Sorry for not producing the clean diff. I didn't make it, since more changes may follow. As for now, the commit history [1] should provide the changes i've done for all of the problems except the 1.-st one. Note that 4.-th issue is critical and 3.-rd is serious. This first one leads to a trap on lua modules loading after destroying of some state. [1] https://github.com/druga/netbsd-lua/commits/master/sys/modules/lua/lua.c -- dukzcry
