anon2 (anon.delete@this.anon.com) on March 15, 2021 4:53 am wrote:
> Simon Farnsworth (simon.delete@this.farnz.org.uk) on March 15, 2021 3:12 am wrote:
> > anon2 (anon.delete@this.anon.com) on March 15, 2021 1:58 am wrote:
> > > Anon (no.delete@this.spam.com) on March 14, 2021 11:49 pm wrote:
> > > > Linus Torvalds (torvalds.delete@this.linux-foundation.org) on March 14, 2021 4:58 pm wrote:
> > > > > That kind of thing could be useful for a microkernel (not that I believe in the
> > > > > concept - I continue to be of the opinion that microkernel proponents are overplaying the advantages,
> > > > > and underplaying the very real issues with communication and sharing).
> > > >
> > > > In several places I saw Linux being classified as "microkernel", I never touhgt
> > > > this classification have any relevance, but now I read you bashing the concept.
> > > >
> > > > So, is Linux a microkernel after all?
> > >
> > > No. It has taken some concepts and applied them where they are are a good fit
> > > (e.g., to implement userspace device drivers for certain classes of device).
> > >
> > > > What is the true concept of microkernel?
> > > >
> > >
> > > Traditionally it is a minimal kernel that supports only thread scheduling, low level interrupt handling,
> > > IPC, and perhaps low level virtual memory management. The
> > > rest of the kernel services are built with threads
> > > (which may or may not be in different address spaces and privilege modes) on top of that base.
> > >
> > > It sounds like such a nice clean idea that even experienced computer scientists
> > > and engineers throw away careers trying to make it work like a monolithic kernel.
> > > The reality is not all problems can be decomposed into "clean, simple".
> > >
> > It also promises a route to extreme stability; the core kernel does IRQ handling, a simple form of
> > IPC, address spaces and task switching (noting that it's up to the user of these facilities to pair
> > tasks with address spaces), and nothing else, and hence in theory can be made completely bug free.
>
> In theory so can the core of a monolithic kernel.
>
The difference is that stuff outside the core of a monolithic kernel can disrupt the functioning of the core. The attractive theory of a microkernel is that the trusted base that must be bug free is small, and the microkernel core can arrange so that failures of any other component of the system do not break the core (memory protection etc), thus ensuring that the system is "up" (for some value of "up") even if only the core works.
> >
> > Then, whenever another component of the system fails, you "merely" have to kill and restart
> > it to return to normal operation - if everything is built to handle crashes, then this Just
> > Works. In practice, life is not that simple, and designing your tasks to handle a crash and
> > restart cleanly is also a hard problem, especially in the face of real hardware behaviour.
>
> Killing and restarting things is haphazard and no vast improvement to stability.

Mmm, but it's oh-so-seductive an idea in theory; you've reduced the proof required to demonstrate that your system is reliable from "every line of code is bug-free" to "the minimal core is bug-free, and all non-core functions can be killed and restarted if they exhibit a bug without affecting functionality".

It sounds so nice[1]; you've simplified the problem of the perfectly stable kernel. The only catch is that practically "all non-core functions can be killed and restarted if they exhibit a bug without affecting functionality" is not much easier (if it's easier at all) than "every line of code is bug-free".

[1] And, in a dysfunctional engineering organisation, it is nice, because you can pass blame on whenever anything outside the core causes a system problem, as the only way for that to happen is if someone else has failed to write code that can be killed and restarted without affecting functionality, and that's clearly Not Your Fault.