5 ms·

Is this still being worked on? That page was last updated in 2010.

by udp 15y ago

iamabhi9 15y ago
That was a Google Summer of Code Project. The code is now part of the NetBSD kernel and being maintained in the official repository. A NetBSD developer gave a talk on this recently at a conference: http://people.freebsd.org/~pgj/bsd_day(2011)/materials/04_mbalmer_kernel_lua.pdf http://people.freebsd.org/~pgj/bsd_day(2011)/materials/04_mb...
bch 15y ago
I can't speak to lunatik, but there is active work bringing Lua into the NetBSD userland[1] (NetBSD -current, which will be tagged NetBSD-6 when it's ready). The notion is that interfaces will be build up around it, allowing scripted access/control of anything from POSIX calls to userland application access (dhcp, gpio[2], for example). [1] http://blog.netbsd.org/tnf/entry/the_lua_scripting_language_in [2] http://cvsweb.netbsd.org/bsdweb.cgi/src/share/examples/lua/?only_with_tag=MAIN
- joe_the_user 15y ago
  After reading your links, I'm still unclear what the advantage of having lua within the kernel is. Remember, this is different than simply using Lua for installation tasks. The Kernel should expose all needed routines to user-level programs anyway.
  - bch 15y ago
    I agree with you; lunatik is related to the other work in that they're both on NetBSD, and I think Marc Balmer is driving the userspace work, and at least familiar w/ the kernel-space work, so there's cross-pollination of talent. Honestly, I think I would rather see the userspace work out of core (ie: not shipping w/ NetBSD) and just put into pkgsrc (NetBSD version of Ports, or dpkg, etc) as a NetBSD-only package. The kernel work -- I'm just not familiar with deep kernel hacking, so perhaps it's my ignorance, but an interp in-kernel doesn't sound attractive to me. I think I'd rather see kernel access pushed to userspace, like FUSE/PUFFS[1] does for filesystems, or even how procfs allows reading/writing kernel from userspace. Jamming more into the kernel, especially an interpretter makes me shake my head. It could be fun as a personal project, or a Clever Hack, but for a shipping production-ready system... reminds me of when RedHat introduced it's in-kernel http server[2]. All that said -- NetBSD is _still_ the most attractive Unix I'm aware of. I occasionally consider a Linux or FreeBSD, but haven't left yet, since NetBSD 1.6 (c. 2002) [1] http://www.netbsd.org/docs/puffs/ http://www.netbsd.org/docs/puffs/ [2] http://en.wikipedia.org/wiki/TUX_web_server http://en.wikipedia.org/wiki/TUX_web_server

Is this still being worked on? That page was last updated in 2010.

by udp 15y ago

Is this still being worked on? That page was last updated in 2010.

That was a Google Summer of Code Project. The code is now part of the NetBSD kernel and being maintained in the official repository. A NetBSD developer gave a talk on this recently at a conference: http://people.freebsd.org/~pgj/bsd_day(2011)/materials/04_mbalmer_kernel_lua.pdf http://people.freebsd.org/~pgj/bsd_day(2011)/materials/04_mb...

bch 15y ago

I can't speak to lunatik, but there is active work bringing Lua into the NetBSD userland[1] (NetBSD -current, which will be tagged NetBSD-6 when it's ready). The notion is that interfaces will be build up around it, allowing scripted access/control of anything from POSIX calls to userland application access (dhcp, gpio[2], for example). [1] http://blog.netbsd.org/tnf/entry/the_lua_scripting_language_in [2] http://cvsweb.netbsd.org/bsdweb.cgi/src/share/examples/lua/?only_with_tag=MAIN

joe_the_user 15y ago
After reading your links, I'm still unclear what the advantage of having lua within the kernel is. Remember, this is different than simply using Lua for installation tasks. The Kernel should expose all needed routines to user-level programs anyway.
- bch 15y ago
  I agree with you; lunatik is related to the other work in that they're both on NetBSD, and I think Marc Balmer is driving the userspace work, and at least familiar w/ the kernel-space work, so there's cross-pollination of talent. Honestly, I think I would rather see the userspace work out of core (ie: not shipping w/ NetBSD) and just put into pkgsrc (NetBSD version of Ports, or dpkg, etc) as a NetBSD-only package. The kernel work -- I'm just not familiar with deep kernel hacking, so perhaps it's my ignorance, but an interp in-kernel doesn't sound attractive to me. I think I'd rather see kernel access pushed to userspace, like FUSE/PUFFS[1] does for filesystems, or even how procfs allows reading/writing kernel from userspace. Jamming more into the kernel, especially an interpretter makes me shake my head. It could be fun as a personal project, or a Clever Hack, but for a shipping production-ready system... reminds me of when RedHat introduced it's in-kernel http server[2]. All that said -- NetBSD is _still_ the most attractive Unix I'm aware of. I occasionally consider a Linux or FreeBSD, but haven't left yet, since NetBSD 1.6 (c. 2002) [1] http://www.netbsd.org/docs/puffs/ http://www.netbsd.org/docs/puffs/ [2] http://en.wikipedia.org/wiki/TUX_web_server http://en.wikipedia.org/wiki/TUX_web_server