The Linux-Insides series is a great resource for learning the details of the Linux implementation and hopefully would help more people contribute to Linux by providing more documentation.

An idea I have is to have a similar series for basic device driver structure and making smaller changes in those places to fix minor annoyances and understand better the OS-machine interaction. Does anyone know of a similar (existing) resource (LDD apart, I guess that book is pretty outdated now.)?

[1] Linux Device Drivers - the O'Reilly book by gregkh and Jim Corbet.

This is quite a coincidence. Last week I've been trying to track down why our Linux kernel takes so long to boot (where "so long" = about 1 second), and using "ignore_loglevel initcall_debug" has been a lot of help.

Here is a typical trace showing initcall timings. It's helpful to download it and use `less -r' to view so you can see the ANSI colours:

http://oirase.annexia.org/tmp/min-seabios.txt

can you explain, what change you made and what improvements you observed?

Absolutely amazing.

One thing that struck my attention is how little comments there are in Linux at times. Consider this:

https://github.com/0xAX/linux-insides/blob/master/Initializa... https://github.com/torvalds/linux/blob/097f70b3c4d84ffccca15...

Not a single line of commentary for something that definitely is not a trivial instruction.

I'm getting the impression that this kind of documentation should be built directly into Linux's source code, creating a document that is self-documenting and both human- and machine-readable.

On a separate note, it would be really nice if Gitlab supported something like ctags for browser-based code navigation...

Great idea to use ctags for code navigation, I created an issue https://gitlab.com/gitlab-org/gitlab-ee/issues/436

Actually I meant Github, but I'd love to see it in Gitlab as well - being able to explore open source projects with ctags using either would be absolutely awesome.

From init/main.c:

"The Bourne shell can be used instead of init..."

An easy way to avoid systemd if the user is more comfortable with using a BSD-style /etc/rc approach to starting services?

The Bourne shell probably doesn't deal with reparented processes properly (at least, that's my experience with working on Docker (PID 1 is a weird process). Not to mention that your shell doesn't propogate signals to children so you'd need quite a bit of shell scripting to make it act like a real init system.

The main reason bash is the fallback init is because it's a good way to fix a borked setup. And "real men don't use init, they just need a root shell" (Linus).