← Back to context

Comment by vezzy-fnord

10 years ago

For instance, the Rump kernels are similar to what OKL4 already did (and deployed) with their device driver reuse.

Reusable device driver frameworks are really old. There was DDE and NetDDE to run Linux 2.4 and 2.6 drivers, currently used by the GNU Hurd.

The good thing about rump kernels is that you're not just reusing device drivers, you're leveraging the whole NetBSD stack and with remarkable portability. They're also interchangeable between kernel and user contexts.

Rump kernels were the logical evolution of NetBSD's already top notch driver framework.

I do not know what OKL4 have done that is similar.

10 comments

vezzy-fnord

Reply
anttiok  10 years ago

The point of rump kernels is not leveraging the whole stack from $OS. It's leveraging the unmodified drivers from $OS without the wholesale import of policies from $OS.

Sure, driver kits are an old idea, but starting from OSKit in the 90's the common fault is that the kits are forks over upstream. Forking is easy, but forking means that maintenance is unbearable unless you happen to be an organization with person-years to spare just to keep up with bugfixes and new features from upstream. Figuring out how to do it without forking (i.e. anykernel architecture which enables rump kernels out-of-the-box) takes more effort, but wins long-term. "proof": DDE is for Linux 2.4/2.6 drivers. NetBSD source tree from a second ago gives you rump kernels.

  • nickpsecurity  10 years ago

    Exactly. It's an evolution of the old stuff and OSkit deserves credit too. Now, just imagine if the concept was discovered and built on sooner. Same with DDE. We'd have more projects doing more stuff. Took a while for one, bright outlier to make some of that potential happen. That's the problem I was illustrating. I like what's going on in Rump Kernel space, though.

    • anttiok  10 years ago

      Not to downplay the prior art, but I'm not sure I can call rump kernels an evolution of the previous work. I certainly hadn't heard about OSKit at least in 2009 (since it's not cited in my 2009 USENIX paper), despite going through several rejections with program committees for rump kernels since 2007. I first heard about DDEKit at my FOSDEM 2011 presentation when someone asked about the differences between rump kernels and DDEKit. I don't know if me being ignorant is more embarrassing for myself or the general computing community.

      I do know that even my first [rejected] paper on rump kernels from 2007 stressed the idea of not forking. Of course, I was young and stupid(er) back then and didn't realize that academic program committees couldn't care less about if something actually worked or not, as long as you could generate nice graphs out of it.

      Yes, I absolutely believe that drivers should be separate from the OS layer. Them being bundled together is a (pre)historic mistake. I agree that we would be in a much better place if projects like OSKit and DDEKit had gotten attention early on.

      5 replies →