• uis@lemm.ee
    link
    fedilink
    arrow-up
    2
    ·
    4 months ago

    Ok, how change of kernel would fix userspace program not reading return value? And if you just want to use microkernel, then use either HURD or whatever DragonflyBSD uses.

    But generally microkernels are not solution to problems most people claim they would solve, especially in post-meltdown era.

    • This particular issue could be solved in most cases in a monolithic kernel. That it isn’t, is by design. But it’s a terrible design decision, because it can lead to situations where (for example) a zombie process locks a mount point and prevents unmounting because the kernel insists it’s still in use by the zombie process. Which the kernel provides no mechanism for terminating.

      It is provable via experiment in Linux by use of fuse filesystems. Create a program that is guaranteed to become a zombie. Run it within a filesystem mounted by an in-kernel module, like a remote nfs mount. You now have a permanently mounted NFS mount point. Now, use mount something using fuse, say a WebDAV remote point. Run the same zombie process there. Again, the mount point is unmountable. Now, kill the fuse process itself. The mount point will be unmounted and disappear.

      This is exactly how microkernels work. Every module is killable, crashable, upgradable - all without forcing a reboot or affecting any processes not using the module. And in a well-designed microkernel, even processes using the module can in many cases continue functioning as if the restarted kernel module never changed.

      Fuse is really close to the capabilities of microkernels, except it’s only filesystems. In a microkernel, nearly everything is like fuse. A linux kernel compiled such that everything is a loadable module, and not hard linked into the kernel, is close to a microkernel, except without the benefits of actually being a microkernel.

      Microkernels are better. Popularity does not prove superiority, except in the metric of popularity.

      • uis@lemm.ee
        link
        fedilink
        arrow-up
        2
        ·
        edit-2
        4 months ago

        This particular issue could be solved in most cases in a monolithic kernel. That it isn’t, is by design.

        It was(see CLONE_DETATCHED here) and is(source)

        Create a program that is guaranteed to become a zombie. Run it within a filesystem mounted by an in-kernel module, like a remote nfs mount. You now have a permanently mounted NFS mount point.

        Ok, this is not really good implementation. I’m not sure that standard requires zombie processes to keep mountpoints(unless its executable is located in that fs) untill return value is read. Unless there is call to get CWD of another process. Oh, wait. Can’t ptrace issue syscall on behalf of zombie process or like that? Or use vfs of that process? If so, then it makes sense to keep mountpoint.

        Every module is killable, crashable, upgradable - all without forcing a reboot or affecting any processes not using the module.

        except without the benefits of actually being a microkernel.

        Except Linux does it too. If graphics module crashes, I still can SSH into system. And when I developed driver for RK3328 TRNG, it crashed a lot. Replaced it without reboot.

        Microkernels are better. Popularity does not prove superiority, except in the metric of popularity.

        As I said, we live in post-meltdown world. Microkernels are MUCH slower.

        • As I said, we live in post-meltdown world. Microkernels are MUCH slower.

          I’ve heard this from several people, but you’re the lucky number by which I’d heard it enough that I bothered to gather some references to refute this.

          First, this is an argument that derived from first generation microkernels, and in particular, MINIX, which - as a teaching aid OS, never tried to play the benchmark game. It’s been repeated, like dogma, through several iterations of microkernels which have, in the interim, largely erased most of those performance leads of monolithic kernels. One paper notes that, once the working code exceeds the L2 cache size, there is marginal advantage to the monolithic structure. A second paper running benchmarks on L4Linux vs Linux concluded that the microkernel penalty was only about 5%-10% slower for applications than the Linux monolithic kernel.

          This is not MUCH slower, and - indeed - unless you’re doing HPC applications, is close enough to be unnoticeable.

          Edit: I was originally going to omit this, as it’s propaganda from a vested interest, and includes no concrete numbers, but this blog entry from a product manager at QNX specifically mentions using microkernels in HPC problem spaces, which I thought was interesting, so I’m post-facto including it.

          • uis@lemm.ee
            link
            fedilink
            arrow-up
            1
            ·
            edit-2
            4 months ago

            First, this is an argument that derived from first generation microkernels, and in particular, MINIX, which - as a teaching aid OS, never tried to play the benchmark game.

            Indeed, first generation microkernels were so bad, that Jochen Liedtke in rage created L3 “to show how it’s done”. While it was faster than existing microkernels, it was still slow.

            One paper notes that, once the working code exceeds the L2 cache size, there is marginal advantage to the monolithic structure.

            1. The paper was written in pre-meltdown era.
            2. The paper is about hybrid kernels. And gutted Mach(XNU) is used as example.
            3. Nowdays(after meltdown) all cache levels are usually invalidated during context switch. Processors try to add mechanisms to avoid this, but they create new vulnreabilities.

            A second paper running benchmarks on L4Linux vs Linux concluded that the microkernel penalty was only about 5%-10% slower for applications than the Linux monolithic kernel.

              1. Waaaaay before meltdown era.

            I’ll mark quotes from paper as doublequotes.

            a Linux version that executes on top of a first- generation Mach-derived µ-kernel.

            1. So, hybrid kernel. Not as bad as microkernel.

            The corresponding penalty is 5 times higher for a co-located in-kernel version of MkLinux, and 7 times higher for a user- level version of MkLinux.

            Wait, what? Co-located in-kernel? So, loadable module?

            In particular, we show (1) how performance can be improved by implementing some Unix services and variants of them directly above the L4 µ-kernel

            1. No surprise here. Hybrids are faster than microkernels. Kinda proves my point, that moving close to monolithic improves performance.

            Right now I stopped at the end of second page of this paper. Maybe will continue later.

            this blog entry

            Will read.

    • areyouevenreal@lemm.ee
      link
      fedilink
      arrow-up
      1
      ·
      4 months ago

      But generally microkernels are not solution to problems most people claim they would solve, especially in post-meltdown era.

      Can you elaborate? I am not an OS design expert, and I thought microkernels had some advantages.

      • uis@lemm.ee
        link
        fedilink
        arrow-up
        2
        ·
        4 months ago

        Can you elaborate? I am not an OS design expert, and I thought microkernels had some advantages.

        Many people think that microcernels are only way to run one program on multiple machines without modyfing them. Counterexample to such statement is Plan 9, which had such capability with monolithic kernel.

        • areyouevenreal@lemm.ee
          link
          fedilink
          arrow-up
          2
          ·
          4 months ago

          That’s not something I ever associated with microkernels to be honest. That’s just clustering.

          I was more interested in having minimal kernels with a bunch of processes handling low level stuff like file systems that could be restarted if they died. The other cool thing was virtualized kernels.

          • uis@lemm.ee
            link
            fedilink
            arrow-up
            1
            ·
            4 months ago

            Well, even monolithic Linux can restart fs driver if it dies. I think.