Booting Linux in Qemu and Writing Pid 1 in Go to Illustrate Kernel as Program

Play a bit with user mode linux [1] the kernel becomes literally a linux program, that I believe you can even debug with gdb (hazy memory as I tried uml last time maybe a decade ago)

In theory you can also attach gdb to qemu running linux, but that's more complicated.

[1] https://en.wikipedia.org/wiki/User-mode_Linux

The fact that it's also a product/program is some brainfucky exercise that might either be an interesting hobby thought experiment OR it might be a very relevant nuance that will be useful to the top 0.1% of professionals who need a 99.9% accuracy, like the difference between classical and relativistic mechanics.

I mean, sure you are right that kernels are programs and that money is a product, and that gravity is not a force. But I am a mere mortal and I will stick to my incorrect and incomplete mental model at a small expense of accuracy to the great advantage of being comprehensible.

I kind of agree, but the kernel as a program serves a pedagogical framing here.

The goal of the post is to make it more tangible for developers, they write programs that are files on the disk, and you can interact with them. That's where the analogy came from.

the author's apparent epiphany is realizing that init is just a program. the kernel is, of course, software as well, but it does injustice to both "program" and "kernel" to lump them together.

https://docs.kernel.org/admin-guide/kernel-parameters.html

Talos is really an interesting linux distribution because it has no classical user space, i.e. there is no such thing as a $PATH including /bin, /usr/bin, etc. The shell is instead a network API, following the kubernetes configuration-as-code paradigm. The linux host (node) is supposed to run containerized applications. If you really want to, you can use a special container to get access to the actual user space from the node.

[1] https://www.talos.dev/ [2] https://github.com/siderolabs/talos/releases/tag/v1.11.5

Go seemed a perfect fit, it is easy to pick up the syntax and see what is going on, but you can still be close to the OS.

The only reason is because I like to be explicit, and I could not know what was set before in the user's environment.

https://raby.sh/sigterm-and-pid-1-why-does-a-container-linge...

I guess also one of the points of using Go was the fact it has own memory management and interacts only with the kernel.

I mean, had you used C, it would be better to compile it statically, otherwise you'd need to put also glibc and ld.so and what else into the initrd, I guess

There is also "b" for block device (e.g. a disk, a partition, or even something like a loopback device) and "p" for FIFOs (similar to mkfifo).

The two numbers are just identifiers to specify the device, so in case of `5 1` it means the systems tty console, while `1 8` would mean "blocking random byte device" (mknod dev/random c 1 8)

> Bailing out, you are on your own. Good luck.

https://unix.stackexchange.com/questions/96720

That is: this seemed like the first 3 minutes of the first lecture on an freshman OS course, or similar in any book on systems. The complication you refer to - is it just from the clutter of adjacent words (EFI, grub, kmod maybe?)

  1. Start other processes - In a typical Linux system, init spawns and manages system services
  2. Reap zombie processes - When child processes exit, init cleans them up
  3. Handle signals - Responds to system shutdown/reboot requests

  For a single-application system (like your game), you can make your game be the init process. When you do this:

  - Your game runs as PID 1
  - When your game exits, the system shuts down
  - You need to handle zombie process cleanup if your game spawns child processes (or use a minimal init wrapper)

  The key difference from containers:

  - ISO/bare metal: Full bootloader → kernel → your game as init. Complete control, boots on real hardware or VMs
  - Container: Relies on host kernel, just isolates processes/filesystems. Much lighter but needs a container runtime

  When to use each:

  - Bare ISO approach:
    - Arcade/kiosk systems
    - Embedded devices
    - Security-critical (full isolation from host)
    - Need specific kernel/hardware access
  - Container approach:
    - Need to run many instances easily
    - Want easy deployment/updates
    - Running on shared infrastructure
    - Don't need custom kernel

  For a statically-linked game, the ISO approach is totally viable and actually simpler than containers if you're deploying to dedicated hardware. You'd just need:
  - Linux kernel
  - Minimal filesystem (your game + maybe /dev, /proc, /sys)
  - Bootloader (GRUB/syslinux)

  Want help setting something like that up?

Do anything necessary from there to boot your game, and record those steps in a script. When that's done you can just point your init cmdline to that script (doesn't even have to be a binary, a script with the #!/bin/bash shebang should just work).

Containers work similarly, except that they don't take the whole system down when their PID 1 exits. That's why containers often don't have a process manager inside, but Linux based operating systems do.

This was 20yrs ago. Gentoo was really a great teacher.