Hacker News Reader

A far better rationale is that it makes fast prototyping easier. You write three lines of Lua, stuff into the kernel, and run. Did the blinkenlights blink? Yes, good, now translate that code into the C driver.

This would be great for something like the Raspberry Pi.

My worry in situations like that is that the `fast prototype' ends up also being the final driver, because it works well enough and nobody feels the urgent need to rewrite in C.

If it works and is sufficiently performant - is there anything wrong with the fact it's written in X, not Y?

And if it doesn't, then there's certainly a reason to optimize.

reminds me of this http://voices.canonical.com/jussi.pakkanen/2013/10/15/c-has-...

"Do these people exist?"

This is spot on. When you hear NetBSD developers arguing about proposals (or commits, ex post facto, like here), there is often mention of "users". But these are mostly fictional.

I think it's safe to say most NetBSD users are comfortable working with C.

I reckon it's not much different with OpenBSD: most changes they make are for the benefit of the developers themselves, to suit personal preferences, than for the benefit of other "users". (And that's perfectly acceptable, I think.) Of course, these changes can benefit users beyond simply those who make them and those who approve them, but those users are not the ones driving the changes.

This is spot on. When you hear NetBSD developers arguing about proposals (or commits, ex post facto, like here), there is often mention of "users". But these are mostly fictional.

I think this is true of much open source software. Just for the sake of example, a few years ago the Gnome devs removed some printer config options because they decided the "users" didn't need so many options. It's not that Gnome doesn't have users, but the developers seemed to have some notion of a type of user that didn't really exist.

I think more often than not, fictional users are used as justification for the addition of some nice-to-have feature, but of course I'm just speculating.

I want to get involved and experiment with NetBSD, but I don't feel comfortable in C, nor C++ for that matter.

Novice developers should not be writing drivers in any language. If you don't have a C background, you're not going to be able to contribute much code to any OS. Besides config files and scripts, NetBSD is nearly 100% C.

If you really want to get into OS programming, I recommend you start with "Computer Architecture" by Hennessy & Patterson along with a course in C programming.

[1] http://www.ohloh.net/p/netbsd

"Novice developers should not be writing drivers in any language."

Well, it might not be such a bad thing to write your stuff in Lua and get the lights blinking as a way to work your way up to C and mainline device driver development. If the device drivers interest the novice programmer, let's encourage that. Its not like there aren't a ton of safeguards between the novice and getting their driver in the mainline.

> We've all seen the arguments about the in-kernel HTTP daemons and whatnot. I tend to be on the side that says that more things should be pulled out.

I always wondered if a lot of components like this could be either sped up, or moved out of the kernel, using a zero-copy messaging system based on splice() / vmsplice() in the Linux kernel (which works by page table remapping as far as I understand). I guess the prime candidate would be device drivers.

That's one approach. Another one attempted sometimes is to go the other way and move the networking stack into userland as well. Depends on your bottlenecks etc

I've used lua in kernel space elsewhere. It links easily, it can invoke your C functions easily, and it's great for testing stuff. I could see some clever hooks being out in so you could custom tune some stuff. I bet typically they use it for testing though.

I'm curious, was this in Linux per chance.

I was looking into embedding lua in a kernel module in Linux, just to hack around with stuff.

How did you strip out the stuff that means it won't compile for kernel space?