Slashdot Mirror
Behind the Scenes in Kernel Development
An anonymous reader writes "Some interesting changes took place in the way the Linux kernel is developed and tested. In many ways, the methods used to develop the Linux kernel are much the same today as they were 3 years ago. However, several key changes have improved overall stability as well as quality. This article takes a look behind the scenes at the tools, tests, and techniques -- from revision control and regression testing to bugtracking and list keeping -- that helped make 2.6 a better kernel than any that have come before it." We might as well mention here (again) that a couple of new kernels are out: leif.singer writes "2.6.3 and 2.4.25 are out, fixing another vulnerability in do_mremap()."
Find a particular functionality of the kernel that really interest you; read any documentation you can find about it; then grep the src till you see the relevant sections of code and start perusing with your $(EDITOR)
Much time is spent teaching people how to write code but never really reading it. This is a perfect example of how to do it and why you would.
BSD is designed. Linux is grown. C++ libs
The announcement for 2.6.3 and 2.4.25 was yesterday, and the vulnerability to which the link in the text above refers was with mremap, not munmap; there's also another vulnerability with mremap mentioned yesterday as an *update* to the kernel announcement.
Emacs: for people who just never know when to
Was here in yesterday's thread about 2.4.25 and 2.6.3 releases.
Software is not supposed to be about how to work around a useability issue. - Ken Barber
and random crashes using ide-scsi (yes I know it's deprecated, but some of us need it).
disable ide-scsi and use latest cdrecord with
dev=ATAPI:x,x,x
instead of
dev=x,x,x
and everything is cool. Don't forget to check lilo.conf. Stop using cdrdao. Ignore xcdroast's "This would be faster is you had ide-scsi enabled" dialogs.
This should apply to almost every kind of ide-scsi use.
Code Reading by Diomidis Spinellis contains a bunch of ideas on ways to comprehend large codebases more easily.
He talks about browsing code, package structures, adding features or fixing bugs in a large codebase, and so on. It's a good read - well worth the money.
The Army reading list
Some more on that history: Larry McVoy on Bitkeeper, kernel development, Linux Torvalds & Bruce Perens
First, you can contribute to Linux and Subversion. You just have to:
a) not use BitKeeper
b) buy a BitKeeper licence
Second, RCS doesn't support concurrent development. That's why we have CVS.
Third, why BitKeeper?
Though CVS has lots of shortcommings (and thats why Subversion exists) and Subversion (SVN) is still labeled "alpha" by it's developers (though in practice it's stable enough to be self hosted and widely used), the real reason has to do with the basic model of CVS and SVN. Two main issues, in my opinion:
a) In CVS/SVN you need write access to the central repository or you can't make proper use of versioning control. Giving write access is a problem for Linux's contribute based development model. BitKeeper doesn't need it.
b) CVS/SVN know about branches but they don't know about merges from one branch into the other. Their view of the repository is a pure spanning tree. Subversion has a "merge" command, but a merge is commited as any other change into the repositoty. BitKeeper knows about previous merges and where they were merged from and uses that information to be smarter at resolving conflicts when you do a merge.
In contribute based development every change to the project has to go through one of few maintainers who can write into the main repository (in Linux's case, there's only one), so proper merging support becomes very important. At some point before BitKeeper, Linus was having trouble keeping up with all the patches people were sending him and people were getting angry with that.
If you don't believe me, you can check the GNU Arch website: http://wiki.gnuarch.org/
They're developing a Free versioning control system very similar to BitKeeper.