alt Hacker NewsAuthor here. It was a bit emotional seeing this on the front page.
My goal with this post and the whole (work in progress) series is to fill the gap between "here are the commands to do X" and "if you want to contribute to the kernel, you need to learn this" style books and tutorials.
I want something in between, for developers who just want a solid mental model of how Linux fits together.
The rough progression I have in mind is:
1. the Linux kernel as "just a program"
2. system calls as the kernel's API
3. files as resources manipulated through system calls, forming a consistent API
4. the filesystem hierarchy as a namespace system, not a direct map of disk layout
5. user/group IDs and permissions as the access control mechanism for resources (files)
6. processes, where all of the above comes together
I deliberately chose Go for the examples instead of C because I want this to be approachable to a broader audience of developers, while still being close enough to the OS to show what's really going on.
As a developer, this kind of understanding has been incredibly useful for me for writing better software, debugging complex issues with tools like strace and lsof, or the proc fs. I would like to help others to gain the same knowledge.
Replies
Really cool post, clear, easy to follow, just the right length and depth. Lookig forward to read the whole series!
Hi! Great article.
I guess also one of the points of using Go was the fact it has own memory management for obtaining memory pages it 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
Another "interesting" related thing I found is that pid 1 signals are handled differently in the kernel. Basically, SIGTERM is ignored and you need to explicitly handle it in your program. Took me quite a while before I found out why my program in a container didn't quit gracefully...
https://raby.sh/sigterm-and-pid-1-why-does-a-container-linge...
Can you also consider adapting Linux from scratch as a part of this series? Or Maybe after this series, you can expand what is learnt to build a minimal Linux distribution. I suppose that might give a good understanding on how to apply this knowledge and a have a foundation on the internals of the os itself.