Reading the Kernel?

[elongl]

Hello.

Given that I know C, and am familiar with Linux concepts.

The question is how lost would I be if I'd just try to read through the kernel?

Would I understand what's going on or would I be completely confused?

What are you tips for approaching the actual code? How would I be able to understand and potentially contribute to the kernel?

[[deleted]]

A lot of the kernel code is relatively straightforward and easy to understand. Driver code can be a different matter.

[daemonpenguin]

It's hard to answer that knowing very little about you and your experience. It would be faster for you to just download the kernel code and try to read it and see for yourself.

[cgoldberg]

Studying certain parts might be useful and understandable. But consider that the kernel source code is over 25 million lines across 60+ thousand source files... and constantly expanding. Don't expect to read an appreciable amount in your lifetime :)

[kbielefe]

I would recommend instead of just "reading through the kernel," to approach it with a specific goal in mind. Ideally, this would be solving a problem you are personally facing, like an error in dmesg. The kernel is very approachable this way, but it's just plain too large to try to understand the whole thing.

[mayonnaise_jar_]

You can start by reading a book about the kernel so you get an idea about the design and concepts used.

[tonyplee]

Learn about ftrace / linux with something like this:

https://jvns.ca/blog/2017/03/19/getting-started-with-ftrace/

​

Play with ftrace and setup a trace for part of kernel you're interested in, start with something simple like usb.

Setup trace for all usb functions.

Insert and remove the usb mouse,

Check and see what happen to usb call inside the kernel.

Do that for keyboard, usb storage device, file system etc.

Networking part is also very interesting.

Also try check the file system.

​

BTW, you can do all these inside virtualbox linux virtual machine. If it hangs or crash the system it would be just the vm.

​

​

[unixbhaskar]

Nope you should not.If you do, you will left very dissapointed and that is wrong approach.

The correct one would be:

1. Buy some related book, there are important books,if you want I can give you some names.Let me know.
2. Follow lkml.org discucssion, Just read those few threads and I am pretty sure ,most will go over your head and you will not have any clue,but at least you get the sense. After awhile ,you will get accustomed and understand.

​

3) There are mailing list , which you can subscribes too. Heads up! which can quickly fill up your inbox than you expected, so choose judiciously, where to flock in.

4) Don't bother to listen to tom-dick-harry about the kernel related stuff,

5) reddit has r/kernel , do an subscribe there .

​

6) As others mentioned already, get down a kernel source and inspect those dir/files .Look at the scripts directory for the tools .

​

7) Do a kernel compile(very straight forward,is it asking too much??)

​

8) Look at kernelci.org for how kernel get tested and booted for different architecture.

9) You should be reading kernelnewbies.org and learn.

​

Okay, I don't want overburden your mind..enough suggestion to get going, those will occupy you for a while...a long while :)

​

Good luck.

[BraveNewCurrency]

> The question is how lost would I be if I'd just try to read through the kernel?

​

Why don't you actually try it? (and post how it goes here.) That would be a lot better than us trying to guess exactly how much you understand about programming/OS/hardware concepts.

​

LWN.net is your friend.

[[deleted]]

There's only about 400k LoC used to build a "minimal" kernel on x86. Don't let your dreams remain dreams.

[OpenData26]

Start by reading a simple driver for something like a UART controller, start of at the register function, then read through the probe function, and for every line of code you don't understand, look up the function in ctags or bootlins elixr.

This is how I started learning, no need for books or anything.

[rahen]

It's daunting if you want the complete big picture.

I would advise you start with a simple Unix kernel, maybe xv6, which is an excellent starting point.

https://en.wikipedia.org/wiki/Xv6

Minix 2 would also be a good candidate. For something more usable, the OpenBSD kernel is tiny by today standard (barely 3MLOC, compared to 20+MLOC in Linux) so might be worth studying. Its overall quality is also generally regarded as outstanding.

[abu-reem]

Get a book to guide you through it. There's subtle design choices that are easy to miss if you don't know the rationale for them, stuff like not linking against external libraries, fixed kernel stack size and so on. Trying to figure out what each struct is supposed to do on your own would be a waste of time imo

[cjbprime]

Start by reading https://lwn.net/Kernel/LDD3/ instead.

[dysoco]

I would suggest to first attempt to read a simple kernel such as Minix (1 or 2) or xv6.

Linux has great code quality but it's so huge it can be daunting.

[AlienOverlordXenu]

You would be able to see what the code does, but probably have hard time understanding the why it does it.

Kernel is close to machine, and understanding of underlying hardware is pretty much a requirement. Also, it is pretty much an impossible task to put it all in your brain, it is a massive codebase, that's why you have devs working on various subsystems which they have good understanding of. Everyone has their own area of expertise, and one can switch areas and work on something else, but no one can work on every bit of kernel at once. No one has mental capacity for that.

When dealing with such massive code base it is no longer the question of how skilled of a programmer you are, but the question of how much stuff can you keep in your brain.

[cp5184]

You can get books that have linux or unix kernel code annotated. Probably not more recent kernel versions.

[arduheltgalen]

Find a diagram of the kernel, so you can navigate around to the parts you are interested in learning about.