How is hardware supposed to be multiplexed in a exokernel?

[exo]

As far as I understand exokernels, applications are compiled with libos-es (which are "just another library" statically linked to the application). Like this

Code: Select all

app       app 
-----    -----
libos    libos
==============
    kernel

libos-es do not communicate between them, so they are not like servers in a microkernel.
What I don't understand is how the kernel is supposed to multiplex the hardware when there are many libos-es running. For example let's take the example of memory-mapped devices. The drivers would be included in each libos (right?), and all the libos-es can write to the memory-mapped registers. Isn't this chaos? What's the kernel doing to avoid chaos?

[Octocontrabass]

The diagram you've got there shows a monolithic exokernel. The kernel can securely multiplex hardware because there are drivers in the kernel, like any other monolithic kernel.

[exo]

The diagram you've got there shows a monolithic exokernel. The kernel can securely multiplex hardware because there are drivers in the kernel, like any other monolithic kernel.

Sorry what does it mean "monolithic exokernel" and what would a "non-monolithic" exokernel look like?
I thought "exo" was like the opposite of "monolithic" and as such everything was *outside* the kernel, including the drivers.

[Octocontrabass]

Sorry what does it mean "monolithic exokernel" and what would a "non-monolithic" exokernel look like?

A monolithic exokernel is one that contains the necessary drivers for securely multiplexing hardware. A non-monolithic exokernel runs drivers in userspace, requiring the libOS to communicate with those drivers for access to hardware rather than the kernel itself.

I thought "exo" was like the opposite of "monolithic" and as such everything was *outside* the kernel, including the drivers.

The traditional exokernel moves everything except drivers outside the kernel, so it's not really the opposite of a monolithic kernel.

[exo]

A non-monolithic exokernel runs drivers in userspace, requiring the libOS to communicate with those drivers for access to hardware rather than the kernel itself

Basically, the moment libos-es "require to communicate" I'm building a microkernel and not an exokernel anymore. Isn't it?

drivers

out of curiosity, is it actually possible to have multiple drivers controlling the same device? Or there must be one and only one driver active at every time?

[Octocontrabass]

Basically, the moment libos-es "require to communicate" I'm building a microkernel and not an exokernel anymore. Isn't it?

Your OS can be both a microkernel and an exokernel at the same time.

out of curiosity, is it actually possible to have multiple drivers controlling the same device? Or there must be one and only one driver active at every time?

Most devices are designed to be controlled by only one driver, and allowing multiple drivers would require insecure cooperation between drivers. However, some devices provide virtual functions that are meant to be controlled by separate drivers so that a hypervisor can map each function to a different virtual machine. You can use those virtual functions to allow separate drivers to share the hardware.