Hacker News Reader

Comment by revelation | Hacker News Reader

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.

View on HN

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

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/

I guess microsoft programmers sort of work the same way.

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

Reply on news.ycombinator.com