Very cool to see this over here :)
A past GSoC project of mine ported the entire Lua test suite to the NetBSD kernel space: https://github.com/gszr/luatests (it needs to be updated... it's been on my to-do list). See also https://github.com/gszr/luaio for some cool IO bindings for Lua in kernel.
This sounds like a really cool feature, but given that I'm not an expert I'm not sure what the practical use-cases for this are. Is it similar to what you can do with something like eBPF in Linux?
Yes, although their scopes are different. For Linux it started as a simple virtual machine for programmable firewall rules. For NetBSD, it's more of a playground to try ideas in kernel space, while rump kernels allow to try kernel ideas in user space.
But what is the practical gain from moving it to kernel-space? Could have at least compared the execution speed against running it normally on user-space to see whether there is any speed-up factor.
Not sure if you're being serious or if this is one of those silly, "why not Rust" responses that are becoming a trope...
Read the article, and you'll see the most glaring reason: Rust doesn't have an interpreter. Also, Rust isn't very portable, so that'd exclude a number of platforms on which NetBSD runs. Add that Rust is not lightweight in the least, and you can see why not Rust.
Also, Lua is much, much more relevant for uses like this, and suggesting that Rust is more mature is just... well, wrong. Lua has been around for ages and has matured quite well.
> Not sure if you're being serious or if this is one of those silly, "why not Rust" responses that are becoming a trope...
I am being serious, and no I never used Rust in my life, but I do know many OSes trust it and are gradually adopting it
> Read the article, and you'll see the most glaring reason: Rust doesn't have an interpreter.
Are you sure we are pointing to the same article? Where does it say anything about that at all?
for the entire small article, the author just plays around with a kernel module that implements lua interpreter somehow with no context presented at all by the author of why there is a kernel module for lua in the netbsd, and that is my doubt.
why is it there rather than being used normally on user-space? what is netbsd goal with integrating lua on the kernel?
And so far nobody has answered me properly.
> Also, Lua is much, much more relevant for uses like this, and suggesting that Rust is more mature is just... well, wrong. Lua has been around for ages and has matured quite well.
Mention me a _serious_ operating system using lua on their kernel side and I'll acknowledge that last sentence.
Be sure we are talking on the same page, we are talking on the context of being used for programming operating systems, is lua mature for that domain?
> Mention me a _serious_ operating system using lua on their kernel side and I'll acknowledge that last sentence.
NetBSD, of course.
> Be sure we are talking on the same page, we are talking on the context of being used for programming operating systems, is lua mature for that domain?
> And for what reason to choose lua over using languages more matured on system programming like Rust..?
...you wanna talk about mature? Rust hit 1.0 in 2015 (https://blog.rust-lang.org/2015/05/15/Rust-1.0.html). Lua hit 1.0 in either 1993 or 94 (https://www.lua.org/history.html is a little fuzzy). As for reasons why Lua is suitable, and Rust is not even remotely suitable for anything core to NetBSD, the obvious one is platform support; NetBSD supports basically every platform to ever be capable of running a unix-like - https://netbsd.org/ports/ has a list. Rust supports... some of these, yes, but only a tiny fraction. Thus, Rust is wholly unsuitable (at this time) for any core component of NetBSD.
I wouldn't call it an answer. In-kernel Lua states[1] have been released with NetBSD 7.0 in 2015 and the work started at least as early as 2013, probably 2011.
NetBSD (and pkgsrc) have a very loyal user base, with quite different expectations from their system than the Linux or FreeBSD user base.
I guess what NetBSD is after (preserving the heritage of the original / early Unixes from which it descends, keeping things simple and stable with minimal requirements while staying as platform agnostic as possible) is a bit of a niche, which also explains the small user base.
More users favor simplicity of usage rather than technical simplicity, run powerful aarch64/amd64 machines rather than exotic / constrained hardware, and are more after the "move fast" model than after long term technical stability and consistency. A large "frenetic" project like Linux simply suits those users better.
