On 2008-02-07, Samuel Baldwin <[EMAIL PROTECTED]> wrote: > What about the other kernel tasks? Just handled by other processes in > userspace?
Mostly, yes. Scheduler may need to be in the kernel. Dunno how it is in existing exokernels, but they do not e.g. include message- passing as microkernels too. That's handled by user side through the kernel-provided memory management. File systems are obviously in user space.. and programs can simply directly allocate disk pages from the kernel, if they don't care to use a file system service. (Over reboots they somehow have to remember their root pages, however. This is actually related to the orthogonal persistence of EROS.) > That'd be very interesting and very cool. Abstraction is > very very good. I wouldn't imagine writing an OS that wouldn't include > device abstraction (for drives, at the very least). Actually, I see the lightweight exokernel as a somewhat of a return to the golden age of DOS. Device drivers can be abstracted as libraries too, when the device doesn't have to be shared, and any program can use the library. The kernel just takes care that no two processes use the device's memory space simultaneously. Now, obviously a sound server that mixes multiple streams is a useful one, as is a display multiplexer, but you don't particularly need a specific low-level driver service, but rather drivers within such much higher level services. Basically a bit like the X server presently is actually, but hopefully without its reliability problems.. (also to consider how to do DRI shit nicely while not giving any bloated and unreliable program full control of such a critical resource). -- Tuomo
