Rump kernel hypervisor

Ideas
#1

Hi all! As developing new drivers and other low-level stack pieces might feel like a constant uphill battle for teams with limited resources, has it ever been considered to piggyback on the concept of rump kernels to help in this regard? I have quite little knowledge of Haiku’s internals at the moment, so would be interested to learn if this can be considered a viable approach for local use case, provided there can be some specific limitations and challenges I am not aware of.

Found this old article for implementing rump hypervisor on top of Linux as a potential starting reference point - https://blog.netbsd.org/tnf/entry/a_rump_kernel_hypervisor_for

#2

Caveat - I know more about the way BeOS works than Haiku…

I think the driver model is quite different and this would kind of break that model. The drivers in BeOS (and I assume Haiku) are enumerated at boot and instantiated. The OS doesn’t “remember” what hardware there should be, it sort of discovers it on each boot. The drivers are also all not part of the kernel, they are modules in their own right. Some are actually loaded by their respective logical services… If you start shimming in stuff to the kernel directly, you make everything a lot more complicated. The BeOS and Haiku kernels as I understand work in a very similar fashion with regards to driver model, and the BeOS kernel is Micro in orientation (though probably someone will argue it is more hybrid) and so I assume the Haiku kernel works in a similar way to support the legacy BeOS driver model. Linux and BSD tend to be monolithic, so shimming in drivers in this way is logically a lot easier… (yeah, the Mach kernel was different, and the way XNU/Darwin works is also different, but they are not pure BSD alike implementations.)

3 Likes
#3

It’s slightly different in Haiku, mainly to better support loading drivers later after boot (for USB devices). But the general idea is the same.

1 Like