Announcement

Collapse
No announcement yet.

Experimental Patches Adapt Linux For A Unikernel Design

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Experimental Patches Adapt Linux For A Unikernel Design

    Phoronix: Experimental Patches Adapt Linux For A Unikernel Design

    Researchers out of Boston University have been working on "Unikernel Linux" to explore application-specific optimizations to the Linux kernel...

    https://www.phoronix.com/news/Linux-Unikernel-RFC

  • #2
    Applications depend on its battle tested code base, large developer community, support for legacy code
    That's a good one!

    Comment


    • #3
      But how does this kernel linking play with the GPL?

      Comment


      • #4
        So this maybe is useful for some embedded use case or some cloud instance. But for most people this is not relevant to their everyday computing.
        Another approach has to be to get Linux running on top of a microkernel, as was previously done with the discontinued MkLinux. Is anyone working on that again?

        Comment


        • #5
          Originally posted by anarki2 View Post
          That's a good one!
          The kernel does have excellent support for legacy code. It's everything else in the Linux ecosystem that sucks balls.

          Comment


          • #6
            Originally posted by uid313 View Post
            So this maybe is useful for some embedded use case or some cloud instance. But for most people this is not relevant to their everyday computing.
            Another approach has to be to get Linux running on top of a microkernel, as was previously done with the discontinued MkLinux. Is anyone working on that again?
            That's the opposite of what this is useful for. Running Linux on top of a microkernel could be useful for robustness or isolation, but it's worthless for integrating the system and application layer. This is about collapsing layers, not about adding new ones.
            You're right that it's useless for regular users tho, but that doesn't mean the feature is worthless.

            Comment


            • #7
              This literally sounds like kernel modules that you load yourself not at boot (or a privileged app does), except that they're using an ABI-stable interface.

              So why not just make the stupid ABI stable once and for all?

              Comment


              • #8
                Originally posted by Weasel View Post
                This literally sounds like kernel modules that you load yourself not at boot (or a privileged app does), except that they're using an ABI-stable interface.

                So why not just make the stupid ABI stable once and for all?
                It doesn't sound like that at all.

                Comment


                • #9
                  Originally posted by sinepgib View Post
                  It doesn't sound like that at all.
                  Orly? So what doesn't sound like that? Let's dissect the first paragraph!

                  Unikernels are specialized operating systems where an application is linked directly with the kernel and runs in supervisor mode.
                  Kernel modules are linked directly with the kernel and run in supervisor mode.

                  This allows the developers to implement application specific optimizations to the kernel, which can be directly invoked by the application (without going through the syscall path).
                  Kernel modules don't use syscalls since they're executed in kernel space already. They call directly into kernel APIs.

                  An application can control scheduling and resource management and directly access the hardware.
                  Kernel modules can control resource management and directly access the hardware. Unsure about scheduling, but...

                  So what doesn't sound like it at all? Be specific.

                  Furthermore, you can use modprobe to load a kernel module. This is a privileged operation/application, but ultimately achieves the same thing: it loads code to execute in kernel space.

                  Why can't this be used to achieve all the goals of "unikernel"??? Privileged app can load a module (and unload it on shutdown, or add a flag to automatically unload it if crashed).

                  Oh wait, not stable ABI. As I said, that's the only problem.

                  Comment


                  • #10
                    Originally posted by Weasel View Post
                    Orly? So what doesn't sound like that? Let's dissect the first paragraph!

                    Unikernels are specialized operating systems where an application is linked directly with the kernel and runs in supervisor mode.
                    Kernel modules are linked directly with the kernel and run in supervisor mode.

                    This allows the developers to implement application specific optimizations to the kernel, which can be directly invoked by the application (without going through the syscall path).
                    Kernel modules don't use syscalls since they're executed in kernel space already. They call directly into kernel APIs.

                    An application can control scheduling and resource management and directly access the hardware.
                    Kernel modules can control resource management and directly access the hardware. Unsure about scheduling, but...

                    So what doesn't sound like it at all? Be specific.

                    Furthermore, you can use modprobe to load a kernel module. This is a privileged operation/application, but ultimately achieves the same thing: it loads code to execute in kernel space.

                    Why can't this be used to achieve all the goals of "unikernel"??? Privileged app can load a module (and unload it on shutdown, or add a flag to automatically unload it if crashed).

                    Oh wait, not stable ABI. As I said, that's the only problem.
                    For a start, because a module is not application code. Then, you can't apply LTO and PGO for a dynamically loaded object because, well, it's dynamically loaded, it loads into memory after the kernel has been initialized. You can't inline its implementation in kernel code, nor make hot paths of the module be close together with hot paths in the main image. Further, in a traditional kernel design you'll still need a bogus pid 1 that essentially does nothing but occupy space.
                    Don't get me wrong, the lack of a stable ABI is a problem. But it is a problem for providing services and drivers that you can load dynamically and keep out of tree. It's unrelated to this.
                    Here, I looked in Wikipedia for you: https://en.wikipedia.org/wiki/Unikernel

                    Comment

                    Working...
                    X