Comment by jacquesm
5 hours ago
> The kernel, the memory manager and device drivers, the language runtimes for managed languages; would these not be written in "systems" languages?
The kernel and memory manager: probably yes, the device drivers: not necessarily, the language runtimes for managed languages: not necessarily.
> On a different note: why should the kernel even handle IPC or scheduling?
Because any other solution will quickly run into chicken-and-the-egg style problems.
> Those take the basic capabilities of context switching, timer management, and memory management.
Yes. But only one timer, the rest should be free to use by other applications.
> Even "core functionality" can be a context switch (or a few) away; is a syscall not just a message to a system server?
No. A syscall is usually defined as a call to a ring one level in from the one where you currently are. But lots of things that are syscalls right now do not necessarily have to be.
> Only the most basic form of communication is necessary to delegate arbitrary functionality, so a true microkernel should only introduce that as an abstraction.
Indeed. And they do.
> Everything else either follows from the hardware or is left to the whims of software.
A lot of the stuff that 'follows from the hardware' can be dealt with at the application level.
> The kernel and memory manager: probably yes, the device drivers: not necessarily, the language runtimes for managed languages: not necessarily.
The parts that touch hardware (or similarly bare kernel interfaces) must be so. Sure, you could split device driver implementations and so on, but somewhere there's a meaningful lower level of software within the system.
> Because any other solution will quickly run into chicken-and-the-egg style problems.
No. The kernel must provide for context switching. It would be like migrating threads IPC, but one-way. No threads, no scheduler, no dedicated data transfer. In other words, the bare minimum necessary to make a sensible abstraction around switching processes.
seL4, according to its developers, is not absolutely a microkernel. I believe the rationale mainly points to the in-kernel scheduler, but seL4's IPC interacts with the scheduler and is noticeably more elaborate than a mere context switch. Even if seL4's IPC is, by most standards, minimal, I do not consider it to be so objectively. I described a meaningfully more minimal alternative.
Delegating scheduling to userspace is trivial. If necessary, designate a scheduler to run if no scheduling decision is available. It has been done before, and the only usual objection is performance.
> No. A syscall is usually defined as a call to a ring one level in from the one where you currently are. But lots of things that are syscalls right now do not necessarily have to be.
Just as hardware interrupts can be abstracted into messages, syscalls can be abstracted into messages. I'm not saying that the hardware implementation directly conforms to the abstraction.