Are Exokernels just like Macrokernels?

[deadmutex]

I've been reading up on the exokernel design and I am still trying to understand the main concepts. From what I have read, an exokernel is mainly responsible for multiplexing hardware to userspace libOSes. Things like physical memory(pages?) and disk blocks are directly exposed. My question is: If the kernel is to be a low-level interface for the hardware, then wouldn't device drivers and bus drivers have to be somehow loaded into the kernel? Wouldn't that also have the same flaw as the macrokernel in which a buggy device driver could crash the kernel?

[Colonel Kernel]

If the kernel is to be a low-level interface for the hardware, then wouldn't device drivers and bus drivers have to be somehow loaded into the kernel?

Not necessarily. The exokernel architecture actually doesn't specify how this is supposed to work, so there are a few options. The "drivers" in an exokernel are really split into three parts -- low-level mechanisms (the actual device-specific parts), policies for multiplexing the hardware, and then higher-level abstractions built upon the lower-level mechanisms (e.g. -- TCP/IP on top of a NIC and packet filter). In all exokernels (by definition), the abstraction part goes in the different libOSes. Typically, the sharing policies are expressed in some kind of special language rather than being implemented in code (e.g. -- downloadable packet filters to multiplex a NIC, or wake predicates to help co-ordinate sharing the of the CPU and unblocking of threads). Your question really applies to the lowest-level device specific parts.

For example -- In Xok (or maybe Aegis, I forget which), the device-specific parts are in the kernel, so they would suffer from the reliability flaw you pointed out. However, there is no reason I can see why you couldn't implement them in a type-safe language instead (I think SPIN does this), or even to put them in their own address space. The kernel would have to trust them to a certain extent anyway, and it would need to be able to send the policies (DPFs, etc.) to them. Otherwise, I see no reason why it wouldn't work. It probably hasn't been done yet for convenience reasons -- because the current exokernels are research projects exploring the separation of hardware protection from abstraction, rather than exploring how to make drivers more dependable. If dependability really turns your crank, check out Singularity.