The Linux operating system was born when I was in high school. When I was in college a few years later, it started to gain traction. By the time I was on my second post-college job in 2004, Linux had gained a major foothold in embedded systems after doing so on the desktop. At that point, the kernel was at version 2.6, and I was just getting introduced to it. Over a decade and a half later, an introduction like the one I got is a little harder to come by, and before long that is bound to be a problem.
According to one estimate, at one point in 2004 the Linux kernel was estimated to have over 4.2 million lines of code. Current estimates peg the code base to be well over six times that at 27.8 million lines of code in the 5.9 release of the kernel. Most of the kernel is not the core, as you might expect, but rather, drivers, which isn’t surprising if you were to look into the kernel source directories. The drivers path is, in a word, huge. Linux supports a lot of hardware, and not just microprocessor architectures.
But that also speaks to the reality that the kernel is less accessible to newbies than it once was. Today’s Linux kernel is much bigger and more complex than when I was introduced. Many aspects of the kernel stand as evidence of this, with data structures changing and sometimes in wholesale fashion and new architectures or other devices being supported all the time. Just from the 2.4 to 2.6 kernel, I saw big changes in the Memory Technology Device (MTD) subsystem when I was knee-deep in it well over a decade ago, and I’m sure that was not an isolated occurrence.
The best way to learn the kernel is from looking over code, especially if you have a guide to it such as a book, a tutorial or a course on it. On all fronts, that is now much more difficult to do, and that’s a big part of the problem. The fact that the code base has grown significantly, as noted earlier, is just one problem, albeit a big one and the most salient evidence of this concern. Reading code without some kind of road map as to what is going on is very difficult no matter what the software product of interest is.
Back in 2004, when I was learning about the kernel, there was much more readily available in the form of books and magazines. Books on the Linux kernel by and large were based on the 2.6 kernel, with some even looking at the 2.4 kernel as a point of comparison to show the evolution of it. The third edition of Linux Device Drivers was released in 2005, and that was as good a reference on the kernel as any since, as noted, device drivers are a big part of the kernel. In addition, books that dealt with the 2.6 kernel were on the scarce side at the time. Linux Journal and Linux Magazine were among the thriving magazines about the operating system, and while neither focused on the kernel, each touched it to some degree and was helpful if you were interested in the kernel as well as being a user or developer of it. The former ceased publication as an online entity over a year ago, but has recently made a comeback under the management of the Slashdot Group.
Looking at what is out there now, however, is troubling. The most recent books on the Linux kernel, at least those of any real prominence, cover the 2.6 kernel and are a decade old. The closest thing to an authoritative reference might be the third edition of Linux Kernel Development by Robert Love, and that book was written in 2010 and is based on the 2.6 kernel. There has not been a newer edition of Linux Device Drivers since the third one. Other books are out there, but leave a little to be desired, and even many of the better books for developers that aren’t first and foremost about the kernel are also a decade or so old.
Go on Amazon.com and search for “Linux kernel” in books, and you further get the idea. The first book that turns up in the search results that was published within the past decade is BPF Performance Tools (Brendan Gregg) by Addison-Wesley, published a little over a year ago. While a very good and highly-rated book by reviewers (I own it but have not read much of it yet), it does not go in-depth into aspects of the kernel the way a book like Linux Kernel Development does. The next book of note is as yet unpublished, Linux Kernel Development Cookbook (Kaiwan Billimoria). Perhaps this will be just what is needed, being based on a more recent kernel, but time will tell.
Interestingly, Andrew Morton, a long-time leader in the kernel’s development who might be the number two person behind Linus himself there, talked about this in the Foreword of the aforementioned book by Robert Love. He picked up on this a decade ago; you can just imagine how much more this is the case given the lack of new materials on the subject. At the Open Source Summit in July 2020, Linus also alluded to some of the concerns with this during one session as well. Among other things, being a maintainer is not easy, as it is a constantly ongoing job and requires reading a lot of e-mails and staying on top of development.
There are courses and tutorials out there, but hardly definitive ones that have separated from the pack. Udemy is great for some subject areas, but the Linux kernel is not one of them. The Linux Foundation offers some training courses on it, but they are not cheap, although given their track record it is probably a good value.
The impact of this is not as limited or straightforward as one might first suspect. Certainly, it doesn’t help to get more people interested in learning the kernel, understanding it, using it and/or improving it. But looking further out, it will also lead to a maintenance challenge. Many components in the kernel don’t have active maintainers right now, and plenty of maintainers are not young engineers fresh out of college. Morton, as one example, turned 61 in July. Additionally, becoming a maintainer requires gaining a lot of knowledge of a subsystem, and that takes time in addition to the management aspects noted earlier. This becomes a pipeline problem of sorts, where fewer people can get going with the kernel and later become more knowledgeable or even experts, and then become a maintainer along the way. Meanwhile, the current maintainers have become so knowledgeable as to essentially become entrenched, but they will not be working on this forever.
Linux is no small part of the software world nowadays; it is very much mainstream now, and I saw it get to that point. For a long time, embedded Linux was the only real-time operating system I had much experience with. It is not, however, lacking in long-term concerns. Chief among them is the kernel’s accessibility to newcomers, something that has been in decline for quite a while now and must be reined in for the sake of the kernel and the many developers who utilize it and the users who benefit from software utilizing it.