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_mb...
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).
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.
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)
A long while ago I hacked some small forth implementation into the Linux kernel. It didn't really do anything useful though, and was a pretty simplistic implementation. It was kind of fun though.
On a system without mandatory access controls [0], absolutely yes. This is what powers some rootkits. [1]
Having a dynamic interpreted language runtime available as just another item in the syscall table [2] would allow arbitrary, unrestricted execution of code that would not even respect resource limitations set in the root user's shell.
I thought more modern languages could be more secure, as they tended to have better overflow protections and so on. So should kernels, but I guess this would be one way to ease features into the kernel (which might be seen as a bad thing).
The short answer will be, it depends on how it's done, and what the scope is. You wouldn't want arbitrary code loaded in.
You could do some fast and very sophisticated manipulation of network traffic streams without requiring that each packet be copied to and from user-space. You wouldn't even have to develop much packet-twiddling code. There is a surprisingly large amount of network-specific open source Lua.
Wireshark, the most popular network protocol analyzer, has dissectors written in Lua. [0]
Nmap, the network mapper and port scanner, has a Lua-based scripting engine to allow session and endpoint property discovery in great detail. [1]
The popular intrusion detection tool Snort Security Platform (SnortSP) has included a Lua interpreter since version 3.0. [2]
Yes, keeping the interpreter in user-space is safer. I have a hard time imagining sandboxing within the language runtime being able to deal with some of the nastier traffic. Perhaps one prudent thing to do with an in-kernel interpreter would be to use a project-specific sanitizer that could reliably escape tokens and keywords found in live traffic.
> old sentimentally attached hardware work so well
I know what you mean. I was running NetBSD on an iMac G4 (the sunflower one) for years and it was great (then the macppc NVidia broke for several months so I switched to OpenBSD).
I use it as a photo server sitting on my bookcase.
Without wishing to get into a flame war, once you try a BSD, the Linux stuff feels a little...raw.
