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.
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.
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 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.
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'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:
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.
"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."
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)
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).
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.
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.