
Getting into Linux Kernel Development - infosecau
https://www.cyphar.com/blog/post/getting-into-linux-kernel-development
======
vezzy-fnord
In all honesty, if you're only a beginning OS hacker, you probably shouldn't
be diving into the Linux kernel unless you have a keen specific interest in
it. Besides all the complexity, both intrinsic and accidental from its
adoption by many heterogenous parties with different interests, it just isn't
architecturally interesting.

You want something to broaden your horizons, and that has a much smaller
surface. Try Minix 3, Plan 9 (or the 9front fork), DragonFly BSD, Genode,
Haiku (BeOS-like), some flavor of illumos, HelenOS or even GNU Hurd.

Besides the easier entry and the higher learning opportunity, you have more of
a chance to make truly major contributions. Something like porting your
favorite package can get your hands dirty quickly.

Arguably, having less conflict of interest from corporate benefactors makes
for a much smoother communication experience, too.

~~~
webaholic
This does not make any sense. Any modern kernel(including the ones you
mentioned) is going to be complex. The only way to get started is to dig in.
Even if you do not make changes right away, trying to understand the code is a
reward in itself.

I also don't get your point about conflict of interest. There is no one
corporate sponsor of Linux. And just because you are a newbie, your patch is
not looked down upon. There is a great community willing to help if you put in
the effort.

~~~
davidw
A while back I did some fooling around with eCos, and wanted to add a floppy
driver. I looked at the Linux one, some from BSD, but settled on the Minix
code: it was a _lot_ simpler and easier to understand. I'm sure it was less
efficient, and handled far fewer weird corner cases, but it was just a matter
of a day or two of hacking to port it to eCos.

It really depends on your goals - if you just want to learn, then Minix is
pretty good.

~~~
pmelendez
Minix 3 is quite efficient. I would suspect that the complexity comes from the
design choices of each OS. Monolithic kernels tend to be more complicated to
be maintained than microkernel OSs.

------
akshat_h
There is also [http://eudyptula-challenge.org/](http://eudyptula-
challenge.org/) which might help in familiarising with the codebase in
sequential steps.

~~~
cyphar
IMO the issue with the Eudypluta Challenge is that they focus on the wrong
part of kernel development (I couldn't get past one of the first few stages
because I couldn't figure out what kind of semantics they wanted for the
Makefile -- something that isn't a problem for most kernel development work).
Kernel development is mostly modification of existing source code, not the
creation of new modules (unless you're adding the support for a new driver).

But yes, anything like that does help familiarise you with the semantics of
writing kernel code.

~~~
akshat_h
I agree. But there are some people(like me) who like a more structured
approach, at least initially. I am no kernel developer, so can't comment in
that respect with the right technical know-how, but for learning something
new, a sequence of challenges is quite good for me to get my feets wet.

------
saboot
As a step 0, people may also be interested in working through Linux From
Scratch where you compile your own kernel, set up the file system and create
your own Linux distribution.

------
NotHereNotThere
I didn't see a link to Aleksa's patch set, so here it is for those curious:
[https://lkml.org/lkml/2015/2/22/204](https://lkml.org/lkml/2015/2/22/204)

~~~
cyphar
I'll update the post to include it, but the actual merged patchset is this
one: [https://lkml.org/lkml/2015/6/9/320](https://lkml.org/lkml/2015/6/9/320).
This is the first part which was merged separately in 4.2:
[https://lkml.org/lkml/2015/6/5/857](https://lkml.org/lkml/2015/6/5/857).

~~~
NotHereNotThere
Ah, my bad. So the patch set I linked is something that is still being worked
on or just didn't get merged yet?

I was a bit confused as the patch set I linked to were from Feb 2015

~~~
cyphar
That was the first version. There's quite a big difference between that
version and the one that got merged (it underwent a complete rewrite because
the original version was _insanely_ unsafe -- I'm surprised it even worked on
my machine).

------
davb
This site is really difficult to read on mobile devices (profile photo
overlaps first paragraph of text, paragraphs are very narrow due to large
padding/margins). A couple of little fixes would make it a much more
comfortable read.

~~~
cyphar
Yeah. I should get around to doing that. I'm not a web developer by trade, so
I've always felt iffy about doing responsive designs. :/

~~~
davb
Feel free to reach out if you need a little help fixing the mobile usability
issues - I'm happy to give some advice. I'm not a designer by trade but
there's nothing huge to fix there - a few small tweaks to the existing design
would make it readable on mobile.

And for new projects, a quick CTRL-Shift-M in Firefox while you're creating
your stylesheets would help verify that things you're adding won't break on
mobile.

(Sorry if I'm sounding negative, but your post might be really good and some
small design tweaks would make it readable on any screen size and help stop
the design getting in the way of your content).

~~~
cyphar
I just fixed it by hiding the image and fixing up the padding on screens
<1000px. That makes it look fine on my phone screen. I'll take a closer look
at it later.

------
shmerl
The article links to Linux coding style guide:
[https://www.kernel.org/doc/Documentation/CodingStyle](https://www.kernel.org/doc/Documentation/CodingStyle)
which has some snarky comments. Is it written by Linus Torvalds?

~~~
cyphar
`git blame Documentation/CodingStyle`

~~~
kasabali
That's not helpful in this case. Most of lines points to 1da177e4, which is:

    
    
        commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
        Author: Linus Torvalds <torvalds@ppc970.osdl.org>
        Date:   Sat Apr 16 15:20:36 2005 -0700
    
        Linux-2.6.12-rc2
        
        Initial git repository build. I'm not bothering with the full history,
        even though we have it.
        ...

