Lua support in the NetBSD kernel

This is partly driven by "we need device drivers and no one understands C anymore", partly because it's cool, but mostly because Moores law is still alive and well. They are putting a scripting language in a kernel ! Forget write your app in python / perl / Ruby then optimise in C - the raw power argument is going to overwhelm us all.

I heard a stat the other day - that a greetings card, the kind that plays a silly tune, has more processing power than all computers on the planet in 1960. And we should expect a similar growth in the next 50 years. Even if that's out by two orders of magnitude just let it sink in.

I think we are at a Cambrian explosion period - where the goal is to try out every possible new body shape, as fast as possible and see which ones get the Darwin seal of approval.

New organisation forms are possible, some for the first time in human history, new ways of thinking and communicating - it's stuff like this that makes one realise the water around the frog is getting hotter.

(Still it's worth remembering that most train companies in 19C England failed and the average return for stockholders was 10% - just because the world will change beyond recognition does not mean industry stocks is a great return)

After all, why use C if you have a working alternative? We just need real world experiments to see if Lua is a working alternative for the kernel.

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

    void avi_unset(unsigned addr, unsigned val)
    {
      unsigned v = __raw_readl(addr);

      v &= ~val;

      __raw_writel(addr, v);
    }

Speed matters, of course, but I suppose that even script speed is enough for many drivers (and, just in case, we have luaJIT).

Don't sure if lua is a right choice, but it's an interesting experiment - and this is what NetBSD is good for.