NetBSD To Support Kernel Development In Lua Scripting

An anonymous reader writes "NetBSD 7.0 will support the Lua scripting language within its kernel for developing drivers and new sub-systems. A Lua scripting interpreter is being added to the NetBSD kernel along with a kernel API so developers can use this scripting language rather than C for developing new BSD kernel components. Expressed reasons for supporting a scripting language in a kernel were rapid application development, better configuration, and "modifying software written in C is hard for users." In a presentation it was said that Lua in the kernel will let users explore their system in an easy way."

Stupid

[Anonymous Coward]

This is, quite possibly, the stupidest kernel feature that has ever been unleashed upon this poor planet.

users?

[gTsiros]

"modifying software written in C is hard for users."

i thought *users* had no business writing device drivers?

of course if they had said "modifying software written in C is hard for programmers." it would gather a fierce shitstorm.

Re:users?

[Mindcontrolled]

The moment you even expect that users should, could, would or even remotely in their most maddened fever dreams WOULD WANT to modify the kernel, you lost it.

Re:users?

[MacTO]

Keep in mind that NetBSD users are quite different from Windows/Macintosh/Linux users (at least on average).

"Hard" may also be a reference to the implementation, rather than the language. Interpreted languages tend to bypass the compile and link part of the development process. This means that interpreted languages are easier to develop with and compiled languages are hard to develop with (at least in some respects). I'd also comment on the arcane nature of C, but I haven't used lua so I don't know if it is any better.

Re: Performance

[larry bagina]

I believe the word you're looking for is "performance".

This is cool already, but with RUMP, OMG

[Anonymous Coward]

This is awesome. What is old is new again. Lisp machines were some of the most beloved equipment for os and ai hackers because of the ability to get to the underbelly easily. This is no different. Making the operating system more approachable makes doing operating systems research easier. This is a great idea.

Besides, it's a natural extension of the RUMP kernel paradigm. If you can run a netbsd kernel, as part of a userspace process on linux, then it only makes sense to be able to talk to these 'kernels' under the hood easily. THIS IS WAY FRIGGING COOL.

Re:long overdue

[stenvar]

It's not mainly for messing with device drivers (although it may be useful for that too).

It's mainly useful for all the stuff that people right now create /proc devices, ioctls, and user-level kernel-related daemons for. Those mechanisms are both slow and complicated. With Lua in the kernel, a lot of that stuff can be handled much more easily, without the overhead of context switches and with much less code.

It probably won't replace all the bloated configuration stuff that already exists, but at least when writing new device drivers and new functionality, developers could save a lot of time and effort.

Re: Performance

[Anonymous Coward]

Multiple execution units, long pipelines and modern caching makes it hard for assembly to be faster than C. The human brain can not visualize the pipeline like a compiler can.

Re:long overdue

[AuMatar]

They use Lua for the non-performance effecting parts of games. They'd never consider using it in the graphics code, which is the bottleneck.

Re:users?

[rubycodez]

go fuck yourself. I'm and Linux and BSD user, I've taken grad courses in kernel architecture of Minix, System V, BSD, VMS. I've modified the kernel of many OS. Not everyone is a windows wuss.

Re:Performance

[10101001 10101001]

Kernel code is like lots of other code: a lot of it is executed rarely and not performance critical. There's setup code, occasional permissions checking, etc.

A lot of it is executed rarely because at least half the code is drivers and one usually doesn't have but one sound card, one (or two) network card, etc vs the hundreds of sound card drivers, hundreds of network card drivers, etc. Further, a major point of the kernel is that it, by design, isn't supposed to be executed a lot because most CPU time should be devoted to user space programs. So, to that end, you could say it's not "performance critical". But, that's more in line with the point that precisely because kernels are generally developed so well, they rarely have "performance critical" code. Once you start throwing scripting into it, I think that goes out the window.

In addition, this is not to replace plain C modules (although it may be useful for prototyping), it's for complex and dynamic configurability.

To this, I could see some benefit. But, honestly, I'd feel it safe and saner if it were a language that was reducible to a FSA. The point that "Dangerous code can be disabled at the byte-code level (prevention of endless loop DoS etc)" in the slide really only works in that context, anyways. In any case, Lua is nothing of the sort.

Right now, there are two ways of handling that. One is to invent complex configuration files and data structures, sometimes even little interpreters. The kernel is full of those. They are error prone, complicated, and require a lot of effort to maintain.

Which is an argument for making a good, universal FSA language. It won't remove the being error prone or complicated because that's the nature of the beast and papering over it with a Turing complete language is no sort of answer. But having them all share the same language makes sense from a maintenance standpoint. For example, the BPF was repurposed for syscall filtering--a little admission that I'm not sure entirely where BPF stands language wise although I don't think it's turing complete--which could probably be refactored into a more general filtering language which could be refactored into an even more generic FSA language which could likely be used to refactor a lot of other code.

The other is to put complex decision making into user-space, but that involves context switches and other overhead. It also means lots of special-purpose and redundant code, and lots of documentation and complexity. The kernel uses both of those strategies extensively, one reason why it's so big.

Generally speaking, context switches aren't a big deal in most OSs/kernels today. Yes, certainly having context switches means an extra overhead and stuffing some code or even all code in the kernel would certainly speed it up. And certainly if a lot more code moved into user space would be measurably slower. But kernel design today seems to try to have a balance between the two, especially with considerations of stability and security. The fact is, lots of code is special-purpose because it's for specific hardware. And code being redundant is more a function of maintaining multiple trees--which admittedly having a single kernel allows a lot of unity--but there's no reason that out-of-kernel-space means out-of-the-kernel-source if the code is still rather kernel specific.

After all, the whole point is precisely that a lot of potential kernel code is "executed rarely and not performance critical" yet remaining outside kernel memory gives the system greater protection and hence speeds up development and generally makes the code easier to maintain. Documentation is a wholly separate beast, in any case, and that's more a point of maintainers or distributors demanding good documentation before code is accepted.

Putting Lua+LuaJIT in the kernel is likely faster than either of th

Re:Stupid

[Anonymous Coward]

No, if you understand how Lua glues C code together, this is brilliant.