4 ms·
Anybody has a link that explains their motivations? There's a lot of speculation in this thread but surely NetBSD being an open community there must have been a
by simias 13y ago
Anybody has a link that explains their motivations? There's a lot of speculation in this thread but surely NetBSD being an open community there must have been a public discussion before they merged that in?
I write linux drivers for a living and I must say it puzzles be a bit. There are times C falls a bit short (if only by its syntax and idiosyncracies). There are times I wish I could use something like a subset of C++ (for templates and destructors mostly) or maybe Rust these days. But a scripting language?
You can already write drivers in userland (using /dev/mem for instance). You can already write device drivers any way you like that way. One of the main limitations is IRQ handling, but do they propose handling IRQs in a scripting language? Maybe I'm too close minded (or just brainwashed by years of C) but it sounds like a recipe for madness.
I actually used lua to write a small userland test driver (it was convenient because the lua interpreter is very small and easy to compile and cross-compile).
It was quite painful really. There's no builtin bitwise operator (although it's now in the standard library), all integers are stored as double floating point values (floating point in the kernel is hardly ever needed and usually very poorly supported). Using integers and bitwise operator is like all you do in a kernel driver (ok, I'm exaggerating, but not by a lot).
I guess they might have changed the syntax a little bit (and use ints instead of doubles for storing integers) but then it means their lua is not compatible with the "real" lua so you can't prototype your code in userland with any stock lua build.
I dug up my userland test driver code, here's what the naughty bits look like:
function avi_unset(addr, val)
local v = assert(devmem.read32(addr))
v = bit32.band(v, bit32.bnot(val))
avi_write(addr, v)
end
For reference here's what it'd look like in C and its bitwise operators:
void avi_unset(unsigned addr, unsigned val)
{
unsigned v = __raw_readl(addr);
v &= ~val;
__raw_writel(addr, v);
}
- pjmlp 13y agoSymbian, BeOS, Windows and Mac OS X have C++ support for kernel drivers, just as info.
- adamnemecek 13y agoDoes anyone still write drivers for BeOS?
- pjmlp 13y agoYes, after all Haiku is pretty much alive, https://www.haiku-os.org/ https://www.haiku-os.org/
- adamnemecek 13y agoI'm aware of Haiku. Does anyone actually still write drivers for it though?
- pjmlp 13y agoSince they still have developers and keep on participating on Google Summer of Code, I would say yes.
- pygy_ 13y agoI won't address your general point, because, I never wrote any drivers, but the following may appease some of your concerns. Changing the number type in Lua is only a few #DEFINEs away. See http://www.lua.org/source/5.2/luaconf.h.html#LUA_NUMBER http://www.lua.org/source/5.2/luaconf.h.html#LUA_NUMBER and the comment above it. Regarding the lack of infix bitwise operators: usually, the functions are cached in locals. It is not as readable as C, but less bulky than what you wrote: local band, bnot = bit32.band, bit32.bnot function avi_unset(addr, val) local v = assert(devmem.read32(addr)) v = band(bnot(v), val) avi_write(addr, v) end If it became apparent that infix operators were needed, adding them to the VM is trivial (There's a power patch for Lua 5.1, and a patch for Lua 5.2 was recently posted in the mailing list). If you want to use the stock VM, you can still use a preprocessor (which makes things a bit more cumbersome).
- simias 13y agoI remember looking at this LUA_NUMBER but I wondered if changing it to an integer type would break something, it's not explicitly mentioned that you can use an integer type there. I'm sure it can be done but it still means that your custom lua will behave a bit differently than the "stock" lua (especially when it comes to things like roundings and overflows). That might be a bit problematic if you prototype your code on one and then attempt to run on the other. As for your improved code I didn't know I could do that, it does look much better indeed. Again, maybe I'm just nitpicking but my main point was that lua, scripting language or not, just didn't seem better suited than C at writing device drivers. That being said, having a good in-kernel REPL would revolutionize kernel hacking, but it seems very hard to do right. Lots of kernel code is very timing-sensitive and you can't afford to wait for user input when you're in a critical path. Just look at the difficulty to implement proper kernel debugging to get a taste of it. The thing is, the NetBSD people know that and more and yet they decided to go with it. I would be very interested to know their objective/motivation. I googled a bit around and found this: http://netbsd-soc.sourceforge.net/projects/luakern/ http://netbsd-soc.sourceforge.net/projects/luakern/ The page mentions some use-cases (like power management and packet filtering) but those can already easily be handed to the userland through the sysfs and tun/tap interfaces for instance. I don't get what problem it's trying to solve.