6 ms·

Kernel programming is an eternal struggle between people trying to pull more into the kernel for performance, and people trying to pull stuff back out for safet

Kernel programming is an eternal struggle between people trying to pull more into the kernel for performance, and people trying to pull stuff back out for safety and modularity. 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. > This is partly driven by "we need device drivers and no one understands C anymore" I don't buy this argument. Who are the people * Using NetBSD * having cutting-edge hardware for which drivers don't exist * deciding to write device drivers * that have device specs/docs needed to write them * that don't know/want to use C * that would do it if only they could write it in a scripting language? Do these people exist? I assert that the far more common case is that the device specs, documentation, BIOS, etc. aren't accessible. If that's true, they couldn't write the driver regardless of the language, C is hardly the limiting factor here

gwu78 13y ago
"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.
- groovy2shoes 13y ago
  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.
- plextoria 13y ago
  I want to get involved and experiment with NetBSD, but I don't feel comfortable in C, nor C++ for that matter.
  - thelukester 13y ago
    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 http://www.ohloh.net/p/netbsd
    - protomyth 13y ago
      "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.
tedunangst 13y ago
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.
- voltagex_ 13y ago
  This would be great for something like the Raspberry Pi.
- agumonkey 13y ago
  reminds me of this http://voices.canonical.com/jussi.pakkanen/2013/10/15/c-has-become-a-scripting-language/ http://voices.canonical.com/jussi.pakkanen/2013/10/15/c-has-...
- koralatov 13y ago
  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.
  - drdaeman 13y ago
    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.
chubot 13y ago
> 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.
- ketralnis 13y ago
  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
TheCondor 13y ago
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.
- deutronium 13y ago
  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?

gwu78 13y ago

"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.

groovy2shoes 13y ago
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.
plextoria 13y ago
I want to get involved and experiment with NetBSD, but I don't feel comfortable in C, nor C++ for that matter.
- thelukester 13y ago
  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 http://www.ohloh.net/p/netbsd
  - protomyth 13y ago
    "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.

tedunangst 13y ago

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.

voltagex_ 13y ago
This would be great for something like the Raspberry Pi.
agumonkey 13y ago
reminds me of this http://voices.canonical.com/jussi.pakkanen/2013/10/15/c-has-become-a-scripting-language/ http://voices.canonical.com/jussi.pakkanen/2013/10/15/c-has-...
koralatov 13y ago
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.
- drdaeman 13y ago
  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.

chubot 13y ago

> 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.

ketralnis 13y ago
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

TheCondor 13y ago

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.

deutronium 13y ago
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?