Page 1 of 1
How is hardware supposed to be multiplexed in a exokernel?
Posted: Mon Feb 20, 2023 2:00 am
by 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?
Re: How is hardware supposed to be multiplexed in a exokerne
Posted: Mon Feb 20, 2023 6:20 pm
by 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.
Re: How is hardware supposed to be multiplexed in a exokerne
Posted: Tue Feb 21, 2023 12:40 am
by exo
Octocontrabass wrote: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.
Re: How is hardware supposed to be multiplexed in a exokerne
Posted: Tue Feb 21, 2023 12:53 pm
by Octocontrabass
exo wrote: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.
exo wrote: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.
Re: How is hardware supposed to be multiplexed in a exokerne
Posted: Tue Feb 21, 2023 11:40 pm
by exo
Octocontrabass wrote: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?
Octocontrabass wrote: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?
Re: How is hardware supposed to be multiplexed in a exokerne
Posted: Wed Feb 22, 2023 11:24 am
by Octocontrabass
exo wrote: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.
exo wrote: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.