5 ms·

Getting into Linux Kernel Development

106 points by infosecau 11y ago

akshat_h 11y ago
There is also http://eudyptula-challenge.org/ http://eudyptula-challenge.org/ which might help in familiarising with the codebase in sequential steps.
- cyphar 11y ago
  IMO the issue with the Eudypluta Challenge is that they focus on the wrong part of kernel development (I couldn't get past one of the first few stages because I couldn't figure out what kind of semantics they wanted for the Makefile -- something that isn't a problem for most kernel development work). Kernel development is mostly modification of existing source code, not the creation of new modules (unless you're adding the support for a new driver). But yes, anything like that does help familiarise you with the semantics of writing kernel code.
  - akshat_h 11y ago
    I agree. But there are some people(like me) who like a more structured approach, at least initially. I am no kernel developer, so can't comment in that respect with the right technical know-how, but for learning something new, a sequence of challenges is quite good for me to get my feets wet.
  - Graziano_M 11y ago
    And the focus on the damn email attachments. I want to learn to code, not figure out how to use mutt to send attachments that aren't base64 encoded... I can figure that out if/when I actually submit a patch.
vezzy-fnord 11y ago
In all honesty, if you're only a beginning OS hacker, you probably shouldn't be diving into the Linux kernel unless you have a keen specific interest in it. Besides all the complexity, both intrinsic and accidental from its adoption by many heterogenous parties with different interests, it just isn't architecturally interesting. You want something to broaden your horizons, and that has a much smaller surface. Try Minix 3, Plan 9 (or the 9front fork), DragonFly BSD, Genode, Haiku (BeOS-like), some flavor of illumos, HelenOS or even GNU Hurd. Besides the easier entry and the higher learning opportunity, you have more of a chance to make truly major contributions. Something like porting your favorite package can get your hands dirty quickly. Arguably, having less conflict of interest from corporate benefactors makes for a much smoother communication experience, too.
- webaholic 11y ago
  This does not make any sense. Any modern kernel(including the ones you mentioned) is going to be complex. The only way to get started is to dig in. Even if you do not make changes right away, trying to understand the code is a reward in itself. I also don't get your point about conflict of interest. There is no one corporate sponsor of Linux. And just because you are a newbie, your patch is not looked down upon. There is a great community willing to help if you put in the effort.
  - davidw 11y ago
    A while back I did some fooling around with eCos, and wanted to add a floppy driver. I looked at the Linux one, some from BSD, but settled on the Minix code: it was a lot simpler and easier to understand. I'm sure it was less efficient, and handled far fewer weird corner cases, but it was just a matter of a day or two of hacking to port it to eCos. It really depends on your goals - if you just want to learn, then Minix is pretty good.
    - pmelendez 11y ago
      Minix 3 is quite efficient. I would suspect that the complexity comes from the design choices of each OS. Monolithic kernels tend to be more complicated to be maintained than microkernel OSs.
  - shmerl 11y ago
    Yeah, illumos doesn't sound like a simple example.
    - bcantrill 11y ago
      illumos actually has the advantage of a rich set of tooling designed for kernel development (DTrace, mdb, etc.) as well as an ethos of detailed comments -- and it tends to be a bit of a self-selecting community in that it attracts people who value the same. As an example of the adventures of a relative newcomer to illumos, see the excellent writings of Ryan Zezeski, e.g. [1][2][3]. [1] http://zinascii.com/2015/illumos-5498.html http://zinascii.com/2015/illumos-5498.html [2] http://zinascii.com/2014/crossed-signals.html http://zinascii.com/2014/crossed-signals.html [3] http://zinascii.com/2014/a-posix-queue-implementation.html http://zinascii.com/2014/a-posix-queue-implementation.html
NotHereNotThere 11y ago
I didn't see a link to Aleksa's patch set, so here it is for those curious: https://lkml.org/lkml/2015/2/22/204 https://lkml.org/lkml/2015/2/22/204
- cyphar 11y ago
  I'll update the post to include it, but the actual merged patchset is this one: https://lkml.org/lkml/2015/6/9/320 https://lkml.org/lkml/2015/6/9/320. This is the first part which was merged separately in 4.2: https://lkml.org/lkml/2015/6/5/857 https://lkml.org/lkml/2015/6/5/857.
  - NotHereNotThere 11y ago
    Ah, my bad. So the patch set I linked is something that is still being worked on or just didn't get merged yet? I was a bit confused as the patch set I linked to were from Feb 2015
    - cyphar 11y ago
      That was the first version. There's quite a big difference between that version and the one that got merged (it underwent a complete rewrite because the original version was insanely unsafe -- I'm surprised it even worked on my machine).
davb 11y ago
This site is really difficult to read on mobile devices (profile photo overlaps first paragraph of text, paragraphs are very narrow due to large padding/margins). A couple of little fixes would make it a much more comfortable read.
- cyphar 11y ago
  Yeah. I should get around to doing that. I'm not a web developer by trade, so I've always felt iffy about doing responsive designs. :/
  - davb 11y ago
    Feel free to reach out if you need a little help fixing the mobile usability issues - I'm happy to give some advice. I'm not a designer by trade but there's nothing huge to fix there - a few small tweaks to the existing design would make it readable on mobile. And for new projects, a quick CTRL-Shift-M in Firefox while you're creating your stylesheets would help verify that things you're adding won't break on mobile. (Sorry if I'm sounding negative, but your post might be really good and some small design tweaks would make it readable on any screen size and help stop the design getting in the way of your content).
    - cyphar 11y ago
      I just fixed it by hiding the image and fixing up the padding on screens <1000px. That makes it look fine on my phone screen. I'll take a closer look at it later.
- qu4z-2 11y ago
  Linux kernel development is also really difficult on mobile devices...
saboot 11y ago
As a step 0, people may also be interested in working through Linux From Scratch where you compile your own kernel, set up the file system and create your own Linux distribution.
shmerl 11y ago
The article links to Linux coding style guide: https://www.kernel.org/doc/Documentation/CodingStyle https://www.kernel.org/doc/Documentation/CodingStyle which has some snarky comments. Is it written by Linus Torvalds?
- cyphar 11y ago
  `git blame Documentation/CodingStyle`
  - kasabali 11y ago
    That's not helpful in this case. Most of lines points to 1da177e4, which is: commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Author: Linus Torvalds <torvalds@ppc970.osdl.org> Date: Sat Apr 16 15:20:36 2005 -0700 Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. ...

106 points by infosecau 11y ago

There is also http://eudyptula-challenge.org/ http://eudyptula-challenge.org/ which might help in familiarising with the codebase in sequential steps.

cyphar 11y ago
IMO the issue with the Eudypluta Challenge is that they focus on the wrong part of kernel development (I couldn't get past one of the first few stages because I couldn't figure out what kind of semantics they wanted for the Makefile -- something that isn't a problem for most kernel development work). Kernel development is mostly modification of existing source code, not the creation of new modules (unless you're adding the support for a new driver). But yes, anything like that does help familiarise you with the semantics of writing kernel code.
- akshat_h 11y ago
  I agree. But there are some people(like me) who like a more structured approach, at least initially. I am no kernel developer, so can't comment in that respect with the right technical know-how, but for learning something new, a sequence of challenges is quite good for me to get my feets wet.
- Graziano_M 11y ago
  And the focus on the damn email attachments. I want to learn to code, not figure out how to use mutt to send attachments that aren't base64 encoded... I can figure that out if/when I actually submit a patch.

vezzy-fnord 11y ago

In all honesty, if you're only a beginning OS hacker, you probably shouldn't be diving into the Linux kernel unless you have a keen specific interest in it. Besides all the complexity, both intrinsic and accidental from its adoption by many heterogenous parties with different interests, it just isn't architecturally interesting. You want something to broaden your horizons, and that has a much smaller surface. Try Minix 3, Plan 9 (or the 9front fork), DragonFly BSD, Genode, Haiku (BeOS-like), some flavor of illumos, HelenOS or even GNU Hurd. Besides the easier entry and the higher learning opportunity, you have more of a chance to make truly major contributions. Something like porting your favorite package can get your hands dirty quickly. Arguably, having less conflict of interest from corporate benefactors makes for a much smoother communication experience, too.

webaholic 11y ago
This does not make any sense. Any modern kernel(including the ones you mentioned) is going to be complex. The only way to get started is to dig in. Even if you do not make changes right away, trying to understand the code is a reward in itself. I also don't get your point about conflict of interest. There is no one corporate sponsor of Linux. And just because you are a newbie, your patch is not looked down upon. There is a great community willing to help if you put in the effort.
- davidw 11y ago
  A while back I did some fooling around with eCos, and wanted to add a floppy driver. I looked at the Linux one, some from BSD, but settled on the Minix code: it was a lot simpler and easier to understand. I'm sure it was less efficient, and handled far fewer weird corner cases, but it was just a matter of a day or two of hacking to port it to eCos. It really depends on your goals - if you just want to learn, then Minix is pretty good.
  - pmelendez 11y ago
    Minix 3 is quite efficient. I would suspect that the complexity comes from the design choices of each OS. Monolithic kernels tend to be more complicated to be maintained than microkernel OSs.
- shmerl 11y ago
  Yeah, illumos doesn't sound like a simple example.
  - bcantrill 11y ago
    illumos actually has the advantage of a rich set of tooling designed for kernel development (DTrace, mdb, etc.) as well as an ethos of detailed comments -- and it tends to be a bit of a self-selecting community in that it attracts people who value the same. As an example of the adventures of a relative newcomer to illumos, see the excellent writings of Ryan Zezeski, e.g. [1][2][3]. [1] http://zinascii.com/2015/illumos-5498.html http://zinascii.com/2015/illumos-5498.html [2] http://zinascii.com/2014/crossed-signals.html http://zinascii.com/2014/crossed-signals.html [3] http://zinascii.com/2014/a-posix-queue-implementation.html http://zinascii.com/2014/a-posix-queue-implementation.html

NotHereNotThere 11y ago

I didn't see a link to Aleksa's patch set, so here it is for those curious: https://lkml.org/lkml/2015/2/22/204 https://lkml.org/lkml/2015/2/22/204

cyphar 11y ago
I'll update the post to include it, but the actual merged patchset is this one: https://lkml.org/lkml/2015/6/9/320 https://lkml.org/lkml/2015/6/9/320. This is the first part which was merged separately in 4.2: https://lkml.org/lkml/2015/6/5/857 https://lkml.org/lkml/2015/6/5/857.
- NotHereNotThere 11y ago
  Ah, my bad. So the patch set I linked is something that is still being worked on or just didn't get merged yet? I was a bit confused as the patch set I linked to were from Feb 2015
  - cyphar 11y ago
    That was the first version. There's quite a big difference between that version and the one that got merged (it underwent a complete rewrite because the original version was insanely unsafe -- I'm surprised it even worked on my machine).

davb 11y ago

This site is really difficult to read on mobile devices (profile photo overlaps first paragraph of text, paragraphs are very narrow due to large padding/margins). A couple of little fixes would make it a much more comfortable read.

cyphar 11y ago
Yeah. I should get around to doing that. I'm not a web developer by trade, so I've always felt iffy about doing responsive designs. :/
- davb 11y ago
  Feel free to reach out if you need a little help fixing the mobile usability issues - I'm happy to give some advice. I'm not a designer by trade but there's nothing huge to fix there - a few small tweaks to the existing design would make it readable on mobile. And for new projects, a quick CTRL-Shift-M in Firefox while you're creating your stylesheets would help verify that things you're adding won't break on mobile. (Sorry if I'm sounding negative, but your post might be really good and some small design tweaks would make it readable on any screen size and help stop the design getting in the way of your content).
  - cyphar 11y ago
    I just fixed it by hiding the image and fixing up the padding on screens <1000px. That makes it look fine on my phone screen. I'll take a closer look at it later.
qu4z-2 11y ago
Linux kernel development is also really difficult on mobile devices...

saboot 11y ago

As a step 0, people may also be interested in working through Linux From Scratch where you compile your own kernel, set up the file system and create your own Linux distribution.

shmerl 11y ago

The article links to Linux coding style guide: https://www.kernel.org/doc/Documentation/CodingStyle https://www.kernel.org/doc/Documentation/CodingStyle which has some snarky comments. Is it written by Linus Torvalds?

cyphar 11y ago
`git blame Documentation/CodingStyle`
- kasabali 11y ago
  That's not helpful in this case. Most of lines points to 1da177e4, which is: commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Author: Linus Torvalds <torvalds@ppc970.osdl.org> Date: Sat Apr 16 15:20:36 2005 -0700 Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. ...