I’ve been working on a “Linux Inside Out” series and wrote a post that might interest folks here who like low(ish)-level / OS internals.

The idea is to dissect the components of a Linux OS, layer by layer, and build a mental model of how everything fits together through experiments.

The first part is about the kernel, in the post I:

  • take the same kernel image my distro boots from /boot
  • boot it directly with QEMU (no distro, no init system)
  • watch it panic
  • write a tiny Go program and use it as PID 1
  • build a minimal initramfs around it so the kernel can actually start our process

The goal isn’t to build a real distro, just to give a concrete mental model of:

  • that the Linux kernel is just a compressed file, you can boot it
  • without anything else
  • what the kernel actually does at boot
  • how it hands control to userspace
  • what PID 1 / init is in practice
  • what is kernel space vs user space

Link: https://serversfor.dev/linux-inside-out/the-linux-kernel-is-just-a-program/

I’m the author, would be happy to hear from other devs whether this way of explaining things makes sense, and what you’d add or change for future posts in the series.

Hope you find it useful.

  • utopiah@lemmy.ml
    link
    fedilink
    arrow-up
    1
    ·
    50 minutes ago

    Nitpicking but a line is missing IMHO namely The code of the program: should also suggest which file to edit, e.g potato.go. It might be obviously to anybody working with Go but for others it’s not.

  • Quazatron@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    56 minutes ago

    I’m old enough to remember UML (User Mode Linux). I don’t know if it’s still around, but it was a port of the Linux kernel that you would run as a standard user binary.

  • MonkderVierte@lemmy.zip
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    1 hour ago

    I like the “take things appart, recombine, look what breaks” approach, same line of thought.

    Btw, i think the current tech stack (CPU, initram, X/Wayland server, input handling, pam/polkit) is just shoehorned Desktop on tech made for server and a lot of historical baggage.

  • Goodman@discuss.tchncs.de
    link
    fedilink
    arrow-up
    4
    ·
    5 hours ago

    I took kernel device driver programming as a course in uni. They were still teaching the device driver course but not the operating system course you were supposed to take before that. Always felt like I have been systematically lacking that knowledge because of that. I’m interested!

  • Klumz@feddit.dk
    link
    fedilink
    arrow-up
    5
    ·
    14 hours ago

    Very cool guide, got the kernel running! Looking forward to your next post!

  • rubdos@lemmy.zip
    link
    fedilink
    arrow-up
    5
    ·
    15 hours ago

    Cool! Looking forward to the next post. I’d love to learn about how the kernel and initramfs work together though. For now the magic seems to be in how qemu strings things together.

  • non_burglar@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    11 hours ago

    Are you just reverse-engineering this for fun, or are you trying to learn how qemu builds on a bootstrap?

    • zknd@lemmy.worldOP
      link
      fedilink
      arrow-up
      2
      ·
      2 hours ago

      I am writing a blog post series to make this topic more approachable for others.