[akavel]

I'm not sure if I understand well the "rump kernel"/"anykernel" idea as implemented in NetBSD. Could anybody please help me with that - specifically, how this differs from a microkernel?

My current idea is that I can take the current NetBSD kernel and:

a) for some (any? or only some?) hardware subsystems, ask the kernel (by some switch/config? where?) to run drivers in userspace, in "microkernel-like" way (and thus they reboot transparently in case of failure/bug/crash?), at some performance cost;

b) compile out/disable (? by some preprocessor directive?) some subsystems of the kernel, so that I get a "smaller" kernel e.g. for embedded machines which don't have video-card/GPU hardware;

and probably also combine the both above approaches together - i.e. build a reduced kernel like in (b), and then optionally run any missing subsystems/drivers like in (a).

Is that correct? Or am I wrong?

[joveian]

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.

[akavel]

Uh, so only FS for now? That's sure nice, and a nice start, but I really thought there's more to it. Thanks for the clarification & and details.

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

[joveian]

I just saw this so not sure if you'll actually see this response, but rump kernel doesn't imply Xen or such, that is just a common thing people want to do with them. It just means kernel drivers that can be used outside the kernel. Anykernel refers to a kernel that can be used that way with minimal differences and without modifying individual drivers. So rump kernel is "libkernel" and an anykernel is one way to get a rump kernel.

There is a FAQ with more information at: https://github.com/rumpkernel/wiki/wiki/Info:-FAQ

I'm pretty sure that Antti created these terms, so it is an authoritative definition :).

[akavel]

Thanks. The problem is, I actually have already read the appropriate sections of the FAQ & some rumpkernel.org pages, but I'm still confused. (I've written my original question out of frustration that things didn't become clear after all the reading.) I'm starting to think it may be best to dive in and try reading the "book" referenced in the FAQ (i.e. the Antti's PhD paper). Seems actually very approachable for a regular non-sciency engineer, from first looks. And/or maybe the "tutorial" I've found at https://github.com/rumpkernel/wiki/wiki/Tutorial:-Getting-st...

[anttiok]

"a" is sort of orthogonal to rump kernels, but yes, you can run at least file system drivers transparently as userspace servers (just give -o rump to mount(8)). I've also run a USB modem driver as a userspace server, in the "the kernel I'm running doesn't contain support, but a future kernel revision has" fashion.

For "b", rump kernels don't support "compiling out". Rather, the idea is to "link in" only what you need, as in "don't need file systems in that particular application? well don't link in VFS then".

I'm not sure if you're right or wrong, but maybe the rump kernel FAQ at http://wiki.rumpkernel.org/Info:-FAQ will straighten your thoughts. In the regrettable case that it doesn't, you can always suggestion additional questions.

[akavel]

Actually, I've asked my question after trying to do some basic reading on my own, but it only deepened my confusion, unfortunately. I vaguely remembered that "rump kernels" seemed to mean "assume we're on Xen/KVM/... and make use of that", or a notion of "library kernels" -- one of those two, though not 100% sure which one (or both?). But then from some NetBSD docs/wikis/... it started to look to me like they're adding another term "anykernel" here and there, and then naming with that some microkernel-like stuff, like mounting stuff in userspace, but then not sure why naming the option as "rump", etc -- and all of that made me more and more confused, instead of less. And that's what made me ask here.