OSDev.org :: View topic - simplest possible design

kerravon wrote:

linguofreak wrote:

This, I think, is the problem with microkernels: services that are best implemented as libraries end up shoved out into their own "machines", communicating, after a fashion, over a "network". With a monolithic kernel, the divide between kernel and userspace allows these services to behave as libraries while preventing userspace code from messing with their data. There are ways hardware could be designed to allow services to still be called as libraries while isolating them not only from userspace but from each other, but such designs are not currently common.

Can you elaborate on this a little bit more ..., and can you give an example of a library function that is badly implemented by normal microkernels? Thanks.

I'd use as an example something like managing virtual memory in a user level server process.

Under such a scheme, even servicing a page fault would require a context switch to another user process to service the paging request, possibly reading the page in from the filesystem (which might itself require another context switch), which further might need to read in data from a disk via a driver in yet another user level process (yet another context switch.)

So, a page fault might require 6 user level context switches (page faulting process -> VMM process -> Filesystem process -> Disk driver process, and back again).

Note, it might be that the read from disk takes a long time, dwarfing the context switch times in the grand scheme of things.

The equivalent in a monolithic kernel requires no context switches.

Author:	linguofreak [ Fri Dec 16, 2022 5:18 am ]
Post subject:	Re: simplest possible design
thewrongchristian wrote: kerravon wrote: linguofreak wrote: This, I think, is the problem with microkernels: services that are best implemented as libraries end up shoved out into their own "machines", communicating, after a fashion, over a "network". With a monolithic kernel, the divide between kernel and userspace allows these services to behave as libraries while preventing userspace code from messing with their data. There are ways hardware could be designed to allow services to still be called as libraries while isolating them not only from userspace but from each other, but such designs are not currently common. Can you elaborate on this a little bit more ..., and can you give an example of a library function that is badly implemented by normal microkernels? Thanks. I'd use as an example something like managing virtual memory in a user level server process. Under such a scheme, even servicing a page fault would require a context switch to another user process to service the paging request, possibly reading the page in from the filesystem (which might itself require another context switch), which further might need to read in data from a disk via a driver in yet another user level process (yet another context switch.) So, a page fault might require 6 user level context switches (page faulting process -> VMM process -> Filesystem process -> Disk driver process, and back again). Note, it might be that the read from disk takes a long time, dwarfing the context switch times in the grand scheme of things. The equivalent in a monolithic kernel requires no context switches. You basically get exactly the point I was making, though anything involving the disk is a bad example for the reason you gave; FUSE is an instance of a monolithic kernel taking the microkernel route, and it's workable exactly because disk latency swamps context switch latency. But the point is that a monolithic kernel is essentially a library, and all of its modules/drivers are essentially libraries, and if a given system call doesn't have significant execution latency in the call itself (such as a disk system call needing to wait for the disk), then having it be provided by IPC to a separate process will add latency.

OSDev.org https://forum.osdev.org/

simplest possible design https://forum.osdev.org/viewtopic.php?f=15&t=55967	Page 2 of 2

Page 2 of 2	All times are UTC - 6 hours
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/