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:
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.