Getting into Linux Kernel development "Share"

REF:

Https://www.cyphar.com/blog/post/getting-into-linux-kernel-development

I don ' t know about you, but I ' ve always found the idea of operating system kernels to being some mysterious and esoteric prog Ramming skill. Its importance cannot is overstated of course, but I ' ve always felt that kernel programming and regular programming were t Wo very separate skills.

I ' ve recently had some patches merged into the Linux kernel, and thought it might being interesting to describe what I learnt From the brief dip into the kernel development and how someone the WHO's new to it might go on getting into this space.

A Bit of Backstory

Over the past year or so, I ' ve been fascinated in reading kernel code. It all went through my head, of course, but I thought it is interesting seeing how the syscalls we used every day were imple mented. I ' d been pining for a good enough excuse to dips my toe into this weird and wonderful world of which I knew nothing about.< /p>

As luck would had it, I stumbled upon a feature request in Libcontainer (now part of Runc, and so the bug report had been deleted), and thought to myself "well, it's now or never". The bug report stated "It would is nice if we could limit the number of PIDs in a Cgroup", and I thought it would be A fairly easy project to do. "I ' m quite a dab hand at C, how hard could it is?". The bug report linked to an old Patchset (circa) which would obviously need quite a bit of work to being brought up to D Ate with the current state of the kernel. It turned out that it needed a complete rewrite, because of what much the internal APIs had changed in that time (and the F Act that some of the hooks it depended on were removed because they were incredibly racy).

So, with all the, I am ready to start writing a new version of the same patchset.

Advice for Getting Started

The easiest-to-get started (from-what-I ' ve heard) is-find a driver that doesn ' t work properly or look for some easy -looking bug report. I wouldn ' t recommend going about getting into the Linux kernel the the-I did, I was thrown quite quickly into the deep end With no documentation in sight.

It's also a good idea to find someone on IRC (on ##kernel freenode), or just e-mail maintainers to ask them about what the pro Blem you want to solve is (or even ask them if they has any bugs this you might being able to fix) and how to go about Solvi ng it. Maintainers is people too, so don ' t spam them if they don ' t reply within all minutes of your first email.

Ever-changing APIs

One of the things that Linux prides itself on are the fact that it has a completely stable ABI. This is a interesting contrast to the fact, there is no stable internal API inside the kernel. This, of course, makes perfect sense in the context of the kernel, but it does make reviving old patchsets nigh impossible Without a complete rewrite.

Although, doing complete rewrites of the old patchsets are actually quite a good thing. It means that's get some pointers as to where in the kernel your changes need to be made (without have to do A manual traceback from a syscall or trying grep to the source tree), but it also doesn ' t spoon feeds you. You need-to-figure out which kernel APIs are need to leverage and which locking semantics for you need to obey.

Unfortunately, because of the lack of a stable API, this means that documentation about things like locking semantics and Current APIs are basically non-existent. If you ' re okay with asking people on what would is the best-by-doing something, then you'll be set (Google won ' t reall Y help me here). If you are aren ' t good with asking questions, you might is able to take advantage of some of the debugging tools Linux have AVA Ilable. Things like and is lockdep PROVE_RCU very useful for making sure you ' re following valid locking semantics. But ultimately, you'll need to ask someone a question eventually, you might as well start getting used to emailing around and asking people questions.

Coding Style

Make sure follow the Linux kernel coding style. Most maintainers won't even look at the contents of your patch if the coding style are not followed. Sure, you might isn't agree with some of the points (the 8 column tabs sort of annoy me every once in a while, and the-ch Aracter limit is really annoying) but it's their choice what coding style they with for their projects. Sometimes ' ve got to live and let live.

Iterative development

Once you ' ve got the first version of your patch working and has tested it on your machine (and hopefully some more Machin ES), you ' re ready to send it out to the mailing list. There is scripts to tell the who you should Cc: your patches to, and I ' d recommend using them. If you ' re sending patchsets, I prefer to just send email using git send-email , it's quick and dirty and works pretty well.

A very important thing to make sure if you start sending patchsets are explaining why your patches are so Importan T, how it was beneficial to users, why your method of solving the problem is the best, why the problem is a real problem th At needs to is solved in the kernel, etc. If you don't make a argument for your patch to being merged, it won ' t be merged (you ' re really Y behind your patch).

The first thing that ' ll happen if you send the first version of your patchset to the mailing list are that it'll be Outright rejected. It ' s very uncommon that a patchset is merged immediately. Maybe you could ' ve do something better, maybe you didn ' t grab some locks on the right order, maybe you missed a race con Dition, etc. It's important is dissuaded when your patch gets rejected. It happens to everyone, just take the feedback you got and move on. Sometimes maintainers would reject a patch for very minor things (bad formatting or other such non-functional changes). It's important to take all of the their Considerations on board (unless really disagree with them, in which case You escalate the issue to some other maintainers or people higher-up in the food chain), since they probably know more ABOs UT the code you ' re changing than your do.

After the first round of nits has been fixed, you send out the patches again with your changes pointed out in the cover L Etter. Then you get some more feedback, you update your code or discuss it, and the cycle continues. Depending on what complicated the issue is, it could take up to ten versions to get a version that's good enough to be merged into the kernel. At the point, it's out of your hands. Your Patch would be merged into a maintainer's tree, and then that maintainer's tree would be merged into Linus ' tree at som Probably the next -rc1 .

Why so complicated?

Kernel code is widely considered to be very complicated code. There is whole bunch of weird APIs, that's call out to, with global variables and macros thrown around everywhere. Trying to which code gets executed from a given syscall is quite complicated. It gets even more complicated if you consider the fact that the Linux kernel is basically one of the largest multi-threa Ded programs in existence. Lots of attention have to being paid to potential race conditions, and quite a lot of this is undocumented.

For me, the easiest-to-get to understanding code was to just read it. Dive in feet first, read a sections of code and then read the code of all of the functions it calls out to. Repeat until you ' ve read all of the code that is can. By doing this process for enough of the sections of the kernel, you start getting a idea about how the kernel functions, What kind's APIs to use where, etc.

Linux ' s complexity doesn ' t necessarily come from the fact that it's a kernel (really, kernel space just has a few differe NT rules than user space and you can get used to that idea quite quickly), rather from the fact that it's an Extraord Inarily Large project with thousands of contributors every release.

All ' s well, Ends well

I got an e-mail this morning from Tejun Heo (the maintainer of control groups in the kernel) that's my patches to add the Cgroup has been merged into his tree. This process took me several long months to reach, but that's mainly because of my lack of experience with kernel DEVELOPM Ent. A lot of this stuff are still new to me, and I ' m still learning a lot more about the kernel every day by just reading code And trying to fix bugs.

So, all's well this ends well. Don ' t be afraid of diving into kernel development feet first. Books won ' t help you (they ' re all out of date), but reading the code would. As an old man once told me, "Read the source, luke!"

Getting into Linux Kernel development "Share"