Comment by jacquesm
4 hours ago
> The parts that touch hardware (or similarly bare kernel interfaces) must be so.
That's just a choice and no you are incorrect. It is perfectly possible to deal with hardware in managed languages.
> Sure, you could split device driver implementations and so on, but somewhere there's a meaningful lower level of software within the system.
This is optional. Been there, done that. Many times.
> 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.
Yes, IPC is context switching. Timer interrupts can cause extra context switches.
> 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.
It is a pretty poor implementation in my opinion.
> 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.
It's trivial, except for the little problem that your userspace program can be killed and then you have no scheduler.
> 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.
Ok. If you want to use a different description of the term syscall than is common then that's fine but you should define that up front. Your definition of a syscall simply does not match mine.
> It is perfectly possible to deal with hardware in managed languages.
Perhaps we're using the words in different ways. What I mean is: in order to interact with something, it must either be done directly or through abstraction. If abstraction is used, it must be realized without itself. A language such as Java or C#, at least for performance, must expose some things on a lower level that the runtime normally abstracts away. (Or, say, the OS memory manager can't use virtual memory before it enables virtual memory.) Technically, the lower level could be programmed with a dialect of Java/C# or something like that, or there may be another level of abstraction that hides the details (a compiler generating code in the background, for example). But something has to be the first step at the bottom.
> Yes, IPC is context switching.
(Considering the diversity of how OSes approach context switches/IPC, I use "context switch" to mean "CPU mode/address space switch", more or less.)
Usually, IPC is context switching and overhead. seL4's IPC has overhead involved with scheduling, threads, and message buffering. My design isolates the context switching, which is common to all IPC designs.
> Timer interrupts can cause extra context switches.
I don't see what your point is. I assure you that my system is not uniquely fragile to timer interrupts.
> It's trivial, except for the little problem that your userspace program can be killed and then you have no scheduler.
Then don't let the scheduler be killed. What is the difference between a privileged userspace program and a kernelspace program? Isn't that what microkernels demonstrate? Again, this has been done before.
> Ok. If you want to use a different description of the term syscall than is common then that's fine but you should define that up front. Your definition of a syscall simply does not match mine.
It wasn't quite a definition, though I did write poorly. In the abstract, a syscall can be seen as a message. If IPC ("to a process") is done by putting some data somewhere, setting a few registers to special values, and executing a magic syscall instruction, then a normal syscall can be considered IPC "to the kernel".