NetBSD To Support Kernel Development In Lua Scripting 311
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."
Performance (Score:5, Informative)
Won't that kill performance?
I mean that's the reason we still write kernels in C. Every cycle counts..
Re:Performance (Score:5, Informative)
Re:Performance (Score:3, Informative)
Lua is designed to be a embedded companion language to C. You still use C where it makes sense (i.e. pointer manipulation/performance). You use Lua for expressing higher level logic more easily. Lua is very fast. Writing the same higher level logic in raw C might not be any faster because you have to build up all the infrastructure that Lua has already provided and optimized like associative arrays.
Re:Performance (Score:5, Informative)
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.
In addition, this is not to replace plain C modules (although it may be useful for prototyping), it's for complex and dynamic configurability.
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. 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.
Putting Lua+LuaJIT in the kernel is likely faster than either of those approaches, while at the same time also being easier to maintain and document.