|
|
|
|
|
by joveian
3910 days ago
|
|
There is a difference between what is possible to do with rump kernels and what NetBSD is currently doing with them. The basic point is to be able to use the same code in different contexts, so in theory you could use rump kernels in implementing a microkernel. However, AFAIK NetBSD currently uses it for (optionally) running filesystems in userland (so you can mount potentially corrupted file systems without crashing the kernel) and for testing. Your (b) is a separate thing that has always been possible in NetBSD (there is also loadable kernel module support). More things could be made to work as userland drivers easily but could still require glue to make it actually work. I don't understand the details but there are multiple ways to make the glue and it can be easier if you are trying to get NetBSD drivers to run in NetBSD userland. You can also use rump kernels to make an application that runs directly on Xen, KVM, or hardware or that e.g. uses NetBSD file system code on Linux (or Cygwin) userland. Much of this still need some work to do what you want, but less than writing the drivers from scratch, much less maintining them. rumpkernel.org is starting to have packages for some applications. This doesn't require otherwise using NetBSD. |
|
(I remembered that Haiku got network drivers from some WhatsitBSD, so I thought those are maybe there too, but it seems it was FreeBSD actually, so just some confusion of mine. So no microkernel there, it seems. Bummer.)
As to running on Xen etc, that was what I seemed to vaguely remeber as what rump kernels mean, so I was really confused and surprised to slowly find out that the NetBSD usage of the term seems to diverge quite substantially, as far as I can (or can't?) understand. Hmph.