I love blog posts like this. You're not wrong in saying that the kernel is sort of this magical block box to most engineers (including me). I know how to use systemd and I know how to use bash and I know a few other things, but the kernel has always been "the kernel", and it's something I've never really tried to mess with. But you're right: ulimately the kernel is just a program. Yes, it's a big and important program that works at a lower level than I typically work at, but it's probably not something that is impossible for me to learn some basic stuff around.
I have had a bit of a dream of building a full desktop operating system around seL4 [1], with all drivers in user space and the guts fully verified in Isabelle, but learning about this level of code kind of feels like drinking from a firehose. I would like to port over something like xserver and XFCE and go from there, but I've never made a proper attempt because of how overwhelming it feels.
[1] I know about sculpt and Genode, and while those are interesting, not quite what I want.
You can actually disable most features of the Linux kernel, including multi-user support (everything will run as root). The end result is a stripped down kernel fit for only running your single desired application.
Try working on NetBSD or OpenBSD. You can learn kernel hacking by literally reading the man pages. Changing, rebuilding,and booting your own custom kernel is tremendously exciting.
It reminds me of when people speak of money as a product. Sure, maybe you are right, but I think more of it as something in relation to products/programs than as a product/program itself.
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.
This is a really clean write up, but it is absolutely a happy path. I do feel the kernel is too big to be called a program. It is almost everything you want from comp sci class, router, scheduler, queue, memory manager. There are some interesting things that you have to handle if you do not run and OS and init on hardware e.g. handle signals, how do you shutdown, reap child process. I believe you are always better off with an init process and an OS.
Thank you for this quite perfect blog post (short, interesting, well written). One subject I would be interested in is what are all the parameters a kernel accepts
Talos Linux [1], "the Kubernetes Operating System", is written in Go. That means it exactly works as the little demo here, where the Kernel hands over to a statically compiled Go code as init script.
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.
I would say something a little different. The kernel is a _library_ that has an init routine you can provide the function for. Or put another way, without the kernel your go program would have to have drivers statically compiled into it. This was the world of DOS, btw.
I agree with your point, but I must correct you on DOS: it had device drivers too. :) That's how we used to access mouse input, CD drives, network, extended memory, etc. Yes, it sucked on the graphics and sound; every app basically had to reimplement its own graphics and audio layer from scratch, but the rest was quite abstracted away.
More importantly, a kernel is a platform. Conceptually it isn't that much different than other platforms such as Chrome or Roblox. They all have to care about the lifecycle of content, expose input events to content, allow content to render things, make sure bad things don't happen when running poorly programmed or malicous content, etc.
And updated domain: https://mustafaakin.dev/posts/2016-02-08-writing-my-own-init...
reply