Microkernel?

By: Simon Farnsworth (simon.delete@this.farnz.org.uk), March 16, 2021 4:42 am
Room: Moderated Discussions
anon2 (anon.delete@this.anon.com) on March 15, 2021 8:31 am wrote:
> Simon Farnsworth (simon.delete@this.farnz.org.uk) on March 15, 2021 6:56 am wrote:
> > 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.
>
> Not really unless you mean by a memory scribble, and only true in the case of your microkernel services
> having different memory protection domains, which is often skipped because it's bad for performance.
>
Not just a memory scribble - things like the stuff the Linux NMI watchdog aims to catch are also an issue. The (false) promise of a microkernel is that because you can't refuse to be rescheduled by the core, you have to cope without that.

> And what's more in practice a memory scribble to very core low level task scheduler and interrupt
> handler in OS like Linux is exceedingly rare to bring down the kernel. Not that it never
> happens, but as a class of bugs to eliminate, it would count for almost nothing.
>
> In practice it's actually more complex interactions and logic and concurrency
> bugs, device driver bugs etc that cause large amount of problems. And also one
> piece can disrupt another piece without necessarily direct attack / scribble.
>
And in theory (but not in practice), you can "just" replace the buggy task with a bug-fixed version and everything recovers in a microkernel. Because a monolith has everything combined into one monolith, you have to restart the entire system (absent tools like ksplice) to fix a security issue in your NIC driver.

> > 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.
>
> Becomes rapidly less attractive when said base either is too small to do anything useful by itself, is too slow
> and unscalable to be usable for many problems, or has taken on a bunch of ugly hacks and short cuts which make
> it more complex and reduce or eliminate the hardware protections which would allow you to "trust" it.
>
Indeed - it's theoretically attractive, until you look at what you have to do in practice to get those advantages. At which point, you start wondering if actually, a monolith and more engineering effort in the OS would be better than incredible demands on hardware and on application software.
> > > >
> > > > 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".
>
> What I mean is that in order to usefully do any work, the system *needs* to have all those complex subsystems
> up. Restarting large swaths of services does not mean you can just continue on like nothing happened with
> no disruption. Your filesystem driver detected some corruption and crashes, disk is fscked and repaired
> and service restarted. You can not just go along like nothing happened now because your filesystem no longer
> matches the state of what existed before. So programs with open files have to be restarted.
>
> If your userspace has to cope with such things, then the better (in many cases, e.g., hardware / device driver
> bug) way to go is to halt and restart the system and fail over or bring up your userspace again as it would
> have to with a microkernel crash anyway. And this is exactly what most real systems that require high availability
> opt for. The aggregate is actually simpler and just as if not more robust most of the time.
>
Exactly - it sounds lovely if you can "just" restart failed services and everything recovers, but the practical implications of doing so mean that you end up having to put in a huge amount of effort to cover all the implications of each restart.

The only time this makes any sense at all is if the engineering organisation you're part of is broken; in that specific case, it can be sensible because it means that you, as the core kernel team, get to do well while the system as a whole is useless because the constraints you place on the other teams involved in the system make it impossible for the system to work as desired.

> >
> > 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.
>
>

< Previous Post in ThreadNext Post in Thread >
TopicPosted ByDate
x86 - why unite when you can fragment?anonymou52021/03/12 06:16 PM
  x86 - why unite when you can fragment?Linus Torvalds2021/03/13 01:18 PM
    x86 - why unite when you can fragment?Jon Masters2021/03/13 07:25 PM
      x86 - why unite when you can fragment?Jon Masters2021/03/13 07:44 PM
        x86 - why unite when you can fragment?Yuhong Bao2021/03/13 08:49 PM
        x86 - why unite when you can fragment?tt2021/03/20 09:30 AM
    x86 - why unite when you can fragment?Andrey2021/03/14 04:15 PM
      x86 - why unite when you can fragment?Linus Torvalds2021/03/14 04:58 PM
        x86 - why unite when you can fragment?anonymou52021/03/14 05:31 PM
          x86 - why unite when you can fragment?anon22021/03/14 08:07 PM
        Microkernel?Anon2021/03/14 11:49 PM
          Microkernel?none2021/03/15 12:37 AM
            Microkernel?Anon2021/03/15 01:56 AM
          Microkernel?anon22021/03/15 01:58 AM
            Microkernel?Simon Farnsworth2021/03/15 03:12 AM
              Microkernel?anon22021/03/15 04:53 AM
                Microkernel?Simon Farnsworth2021/03/15 06:56 AM
                  Microkernel?iz2021/03/15 08:10 AM
                    Microkernel?Anon2021/03/15 09:05 AM
                      Microkernel?iz2021/03/16 01:25 AM
                        Microkernel?Andrey2021/03/16 02:54 AM
                          Microkernel?iz2021/03/16 08:36 AM
                            Microkernel?Andrey2021/03/16 10:06 AM
                              Microkernel?anonymou52021/03/16 11:44 AM
                              Microkernel?iz2021/03/21 02:58 AM
                                Microkernel?Andrey2021/03/21 09:34 AM
                  Microkernel?anon22021/03/15 08:31 AM
                    Microkernel?Simon Farnsworth2021/03/16 04:42 AM
            Microkernel?Gabriele Svelto2021/03/15 03:21 AM
              Microkernel?anon22021/03/15 04:56 AM
                Microkernel?Gabriele Svelto2021/03/15 10:41 AM
                  Microkernel?anon22021/03/15 08:00 PM
                    Microkernel?Gabriele Svelto2021/03/16 07:23 AM
                      Microkernel?anon22021/03/16 05:13 PM
                        Microkernel?anon22021/03/16 05:16 PM
                    Microkernel?Gian-Carlo Pascutto2021/03/16 01:40 PM
                      Microkernel?anon22021/03/16 05:53 PM
                        Microkernel?Linus Torvalds2021/03/16 07:25 PM
                          Microkernel?Doug S2021/03/17 09:30 AM
                            Microkernel?Linus Torvalds2021/03/17 10:30 AM
                              Microkernel?Brendan2021/03/17 10:56 PM
                                Microkernel?Michael S2021/03/18 03:47 AM
                                  Microkernel?Brendan2021/03/18 09:07 AM
                              Microkernel?Jose2021/03/18 09:35 AM
                            Microkernel?zArchJon2021/03/18 05:42 PM
                          TransputerRichardC2021/03/17 09:47 AM
                          Microkernel?dmcq2021/03/17 11:15 AM
                            Microkernel?Linus Torvalds2021/03/17 11:59 AM
                              Microkernel?dmcq2021/03/17 12:38 PM
                              Microkernel?Adrian2021/03/17 01:00 PM
                              Microkernel?Ana R. Riano2021/03/18 04:33 AM
                              Microkernel?2021/04/30 04:52 PM
                          Microkernel?NvaxPlus2021/03/17 11:48 AM
                            Microkernel?Michael S2021/03/18 03:32 AM
                              Microkernel?Adrian2021/03/18 04:12 AM
                                Microkernel?dmcq2021/03/18 06:30 AM
                                  Microkernel?dmcq2021/03/18 06:55 AM
                                  Microkernel?Adrian2021/03/18 08:35 AM
                                    Microkernel?---2021/03/18 09:49 AM
                                    Microkernel?dmcq2021/03/18 10:59 AM
                                      Microkernel?dmcq2021/03/18 04:09 PM
                              Microkernel?---2021/03/18 09:27 AM
                          Microkernel?Kalle A. Sandström2021/03/20 06:34 AM
                            Microkernel?---2021/03/20 08:35 AM
                            Microkernel?anon22021/03/21 05:29 PM
            Microkernel?dmcq2021/03/15 04:06 AM
              Microkernel?anon22021/03/15 04:59 AM
                Microkernel?dmcq2021/03/15 11:51 AM
                  Microkernel?anon22021/03/15 08:31 PM
                    Microkernel?dmcq2021/03/16 09:17 AM
                      Microkernel?Jukka Larja2021/03/16 11:22 AM
                        Microkernel?dmcq2021/03/16 04:06 PM
                          Microkernel?Jukka Larja2021/03/17 03:42 AM
                            Microkernel?dmcq2021/03/17 07:00 AM
                      Microkernel?anon22021/03/16 05:26 PM
                    Microkernel?---2021/03/16 10:07 AM
            Microkernel?-.-2021/03/15 08:15 PM
              Microkernel?anon22021/03/15 09:18 PM
                Microkernel?Foo_2021/03/16 03:37 AM
                  Read the thread (NT)anon22021/03/16 05:27 PM
                    Already did (NT)Foo_2021/03/17 02:55 AM
                      Already didanon22021/03/17 03:46 AM
                        Already didEtienne Lorrain2021/03/18 02:31 AM
                Microkernel?-.-2021/03/17 05:04 AM
                  Microkernel?Gabriele Svelto2021/03/17 08:53 AM
                    Microkernel?-.-2021/03/17 02:43 PM
              Microkernel?dmcq2021/03/16 08:40 AM
        x86 - why unite when you can fragment?Konrad Schwarz2021/03/17 10:19 AM
    x86 - why unite when you can fragment?anonon2021/03/15 07:37 AM
Reply to this Topic
Name:
Email:
Topic:
Body: No Text
How do you spell avocado?