Learn How to Contribute to the Linux Kernel: Take the Eudyptula Challenge | Hacker News Reader

Learn How to Contribute to the Linux Kernel: Take the Eudyptula Challenge

linux.com

93 pointsTsiolkovsky31 comments

The main reason in my experience is the complete and utter lack of documentation. It's a bunch of text files that alternatively tell you intricate details about some architecture that died 20 years ago or boast their genius.

Linus likes his C code groomed a particular way, but he doesn't mind if you omit the documentation for that subsystem rewrite. That's why they call it kernel hacking.

I would agree. I've wanted to get into Linux kernel development but there's a huge knowledge barrier. (And admittedly, I do have lots to learning that I'm working on learning now before I can really start contributing code). The biggest issue I found is that Ex. stuff from 5 years ago may or may not be relevant, and it's almost impossible to figure out if that's the case besides digging through the code and mailing list. The ./Documentation folder does hold some good stuff, but it's hard to find things and there's no guarantee it actually still applies or if there have been subtle changes.

I believe this guide is pretty much the most highly rated and is still current:

https://github.com/gregkh/kernel-tutorial

Right. There is a lot of old / stale / bad material out there from 2.6, 2.4, and even earlier kernels... that just doesn't apply or work anymore in 3.x. It's frustrating.

I guess microsoft programmers sort of work the same way.

Although I'm not sure about how they manage the coding of their kernels.

Use the source, Luke.

I'm not usually one to trot out that line, but I've found it is the simplest way to figure out what's going on. Most subsystems are pretty straight forward. The only really hairy place is the scheduler. That's after mucking with most of the device model, ARM specific bits, and networking stack.

It is not only that but he does not like to organize code in a good way and does not care about security too much either. Pax team was asking him to merge in the security patches to mitigate some of the problems inherited from the monolithic design and the lack of kernel and user space memory separation but those efforts were greatly ignored. On the top of these he is suffering from not-invented here attitude (to be fair this is common in the open source community) and license problems as well. This is why everything gets re-implemented in Linux, prime example is dtrace vs. opentap. I think the world deserves a better kernel that is designed for the modern era, security and maintainability kept in mind. There are some interesting work done in few projects already:

https://github.com/cloudius-systems/osv https://os.inf.tu-dresden.de/L4/

http://www.amazon.com/dp/0672329468/

The BSDs are far more approachable, and I recommend starting there for anyone interested in kernel development.

There are books, such as The Design and Implementation of the FreeBSD Operating System (by McKusick): http://www.amazon.com/Design-Implementation-FreeBSD-Operatin...

There are papers, such as Jonathan Lemon's "Kqueue: A generic and scalable event notification facility" presented at Usenix 2001: http://people.freebsd.org/~jlemon/papers/kqueue.pdf

There are kernel interface man pages:

http://www.freebsd.org/cgi/man.cgi?query=SYSCALL_MODULE&sekt...

http://www.freebsd.org/cgi/man.cgi?query=hhook&apropos=0&sek...

There are examples referenced by the man pages:

http://svnweb.freebsd.org/base/head/share/examples/

Indeed and there is a new edition of the Design and Implementation updated for FreeBSD 10/11 http://www.freebsdnews.net/2014/04/02/design-implementation-...

NetBSD is pretty approachable too. With the rump kernel you can run drivers in userspace, so you can use a normal debugger and so on, and not crash the OS you are running.

Thanks for the references!

I actually started to look into FreeBSD kernel code recently. I've found that FreeBSD's ath driver code is cleaner and more straightforward compared to the ath/ath*k drivers in Linux. Not sure if this is coincidence or due to different philosophy between FreeBSD and Linux communities.

I've found similar across the board; I think it boils down to different philosophies/development cultures.

I've been wanting to do something like this for ages. I haven't had a reply back to my sign up email yet, but soon I assume.

What might be really good is if other projects in Linux ran similar courses. The larger projects are inspiring to take part in, but have learning cliffs more than learning curves.

Did you by chance send the email as HTML? The FAQ says they reject those outright.

It will tell you if it has not accepted your email and why.

It came through eventually.

"Please note, all HTML-formatted email will be merrily rejected, please fix your email client to not send HTML email if you wish to do this challenge. Linux kernel mailing lists reject HTML email and so do we."

Oh boy!

How much time does it take to get a first reply? I had sent an email to join this challenge but still haven't received a reply. Note: I sent an email via gmail (plaintext mode)

15 minutes maybe?

Ubuntu offers a guide to fetching the appropriate software dependencies for a build environment, kernel source and configs:

https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel

This link is for contributing to the Linux kernel project, not compiling a kernel.

Consider it a step 0!

I finished this, but I still have no idea where I can actually help (aside from janitorial code cleanups and some vague notion of improving the documentation).

No idea if this is actually a good place to start, but there is the Bugzilla: https://bugzilla.kernel.org/describecomponents.cgi

You finished with all the tasks? They said that at the end you will be maintaining a subsystm.

They are exaggerating :).

I'm curious to know more too. I am a little over halfway done and want to see where the challenges end up. Can you give me some more detail?

You end up adding a minor feature to the FAT filesystem.

In the book "Systems Performance" by Brendan Gregg, there is a section on Kernels--in this case comparing Linux to Solaris--where the author shows a table of Kernel Versions with Documented Syscall Counts.

He states: '...there is a pattern over time: Linux has been adding system calls. Solaris has been removing them...'

Just as a matter of personal opinion, I would personally never jump into Linux Kernel Development simply because I feel there are already 'too many cooks in the kitchen' and it feels as if there is simply not as much clarity when compared to other *nix distributions.

Do I work with Linux? Yes, because this is what is used in my workplace. Would I hack on the Linux Kernel or Network Stack for work purposes? Sure, because it would likely be a group effort to address some problem for instance.

Now would I go home and hack on the Linux Kernel for fun and understanding? Absolutely not.

From the blog post:

> You need a strong knowledge of C in order to participate

From the website:

> A basic understanding of the C programming language is required

A good step taken by the Linux Foundation. I think I'll join the project, it a nice way to rank myself...

Reply on news.ycombinator.com