zknd

Hello everyone,

I've just published the second post in my Linux Inside Out series.

In the first post we demystified the Linux kernel a bit: where it lives, how to boot it in a VM, and we even wrote a tiny init program.

In this second post we go one layer deeper and look at how programs actually talk to the kernel. We'll do a few small experiments to see:

• how our init program (that we wrote in the first post) communicates with the kernel via system calls
• how something like echo "hello" ends up printing text on your screen
• how to trace system calls to understand what a program is doing

I’m mainly targeting developers and self-hosters who use Linux daily and are curious about the internals of a Linux-based operating system.

This is part 2 of a longer series, going layer by layer through a Linux system while trying to keep things practical and approachable.

Link (part 2): https://serversfor.dev/linux-inside-out/system-calls-how-programs-talk-to-the-linux-kernel/

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

As always, any feedback is appreciated.

Hello everyone,

I've just published the second post in my Linux Inside Out series.

In the first post we demystified the Linux kernel a bit: where it lives, how to boot it in a VM, and we even wrote a tiny init program.

In this second post we go one layer deeper and look at how programs actually talk to the kernel. We'll do a few small experiments to see:

• how our init program (that we wrote in the first post) communicates with the kernel via system calls
• how something like echo "hello" ends up printing text on your screen
• how to trace system calls to understand what a program is doing

I’m mainly targeting developers and self-hosters who use Linux daily and are curious about the internals of a Linux-based operating system.

This is part 2 of a longer series, going layer by layer through a Linux system while trying to keep things practical and approachable.

Link (part 2): https://serversfor.dev/linux-inside-out/system-calls-how-programs-talk-to-the-linux-kernel/

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

As always, any feedback is appreciated.

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.

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.

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.