5 ms·

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

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.

DSMan195276 13y ago
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.
- CraigJPerry 13y ago
  I believe this guide is pretty much the most highly rated and is still current: https://github.com/gregkh/kernel-tutorial https://github.com/gregkh/kernel-tutorial
- awda 13y ago
  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.
jokoon 13y ago
I guess microsoft programmers sort of work the same way. Although I'm not sure about how they manage the coding of their kernels.
adestefan 13y ago
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.
- leccine 13y ago
  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://github.com/cloudius-systems/osv https://os.inf.tu-dresden.de/L4/ https://os.inf.tu-dresden.de/L4/
ksk 13y ago
http://www.amazon.com/dp/0672329468/ http://www.amazon.com/dp/0672329468/
teacup50 13y ago
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-Operating-System/dp/0201702452 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 http://people.freebsd.org/~jlemon/papers/kqueue.pdf There are kernel interface man pages: http://www.freebsd.org/cgi/man.cgi?query=SYSCALL_MODULE&sektion=9&apropos=0&manpath=FreeBSD+10.0-RELEASE http://www.freebsd.org/cgi/man.cgi?query=SYSCALL_MODULE&sekt... http://www.freebsd.org/cgi/man.cgi?query=hhook&apropos=0&sektion=9&manpath=FreeBSD+10.0-RELEASE&arch=default&format=html 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/ http://svnweb.freebsd.org/base/head/share/examples/
- justincormack 13y ago
  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-freebsd-operating-system/ 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.
- songgao 13y ago
  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.
  - teacup50 13y ago
    I've found similar across the board; I think it boils down to different philosophies/development cultures.

DSMan195276 13y ago

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.

CraigJPerry 13y ago
I believe this guide is pretty much the most highly rated and is still current: https://github.com/gregkh/kernel-tutorial https://github.com/gregkh/kernel-tutorial
awda 13y ago
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.

jokoon 13y ago

I guess microsoft programmers sort of work the same way. Although I'm not sure about how they manage the coding of their kernels.

adestefan 13y ago

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.

leccine 13y ago
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://github.com/cloudius-systems/osv https://os.inf.tu-dresden.de/L4/ https://os.inf.tu-dresden.de/L4/

ksk 13y ago

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

teacup50 13y ago

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-Operating-System/dp/0201702452 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 http://people.freebsd.org/~jlemon/papers/kqueue.pdf There are kernel interface man pages: http://www.freebsd.org/cgi/man.cgi?query=SYSCALL_MODULE&sektion=9&apropos=0&manpath=FreeBSD+10.0-RELEASE http://www.freebsd.org/cgi/man.cgi?query=SYSCALL_MODULE&sekt... http://www.freebsd.org/cgi/man.cgi?query=hhook&apropos=0&sektion=9&manpath=FreeBSD+10.0-RELEASE&arch=default&format=html 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/ http://svnweb.freebsd.org/base/head/share/examples/

justincormack 13y ago
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-freebsd-operating-system/ 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.
songgao 13y ago
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.
- teacup50 13y ago
  I've found similar across the board; I think it boils down to different philosophies/development cultures.