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
I don't know what they've done in terms of changing things, and I didn't RTFA. What I do know is that I've been using the 2.6 kernel on my new ThinkPad T40, and the machine is FAST, and stable. Hats off to all reponsible.
libertarianswag.com
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
Actually, there's a new version of cdrdao out that supports ATAPI burners without the need of ide-scsi.
Also, I'm not sure what hardware the original poster has, but I had no problem with 2.6.1 or 2.6.2. As always, YMMV.
You mean something like the 2.6.0-test series? Which started with the following post, 5 months before the final 2.6.0 was released:
Linus Torvalds: Linux 2.6.0-test1
Jul 14 2003, 09:16 (UTC+0)
Ok, the naming should be familiar - it's the same deal as with 2.4.0.
One difference is that while 2.4.0 took about 7 months from the pre1 to the final release, I hope (and believe) that we have fewer issues facing us in the current 2.6.0. But very obviously there are going to be a few test-releases before the real thing.
The point of the test versions is to make more people realize that they need testing and get some straggling developers realizing that it's too late to worry about the next big feature. I'm hoping that Linux vendors will start offering the test kernels as installation alternatives, and do things like make upgrade internal machines, so that when the real 2.6.0 does happen, we're all set.
Linus
"Linux Kernel Development" is a nice introduction book by kernel hacker Robert Love, and it already covers the 2.6 Kernel.
It doesn't go into too much detail, but it gives a very good overview and basic understanding of the issues you have to deal with in the kernel! I'm currently reading it and getting enlightened :-)
I thought rmmmod support was removed or at least deprecated in the latest kernel? Any kernel hackers care to clear this up?
Why would beginners be installing a new kernel? The distros would have the latest features patched into their supported kernels. In any case, if you are installing kernels, you should at least read kernel traffic.
I highly suggest picking up a copy of the Linux Core Kernel Commentary. The first part of the book contains the code of the majority of the "core" kernel components, and the second part explains the code. It's slightly out of date, but still a good read.
> Does the fact that Diomidis Spinellis has
:-) Yup, he talks about that a bit in the book, and makes the point the to IOCCC winners usually employ the preprocessor in their entries.
:-)
> repeated won the International Obfuscated
> C Code Contest (IOCCC)
Heh
Then he goes on to suggest that preprocessor usage be minimized in 'normal' programming activities
The Army reading list
dev=ATAPI:x,x,x
dev=/dev/hdc works for me. Seems simpler.
Alas, while I'm in doubt about the "easily assimilated" part, they have a lot of reports there att ing/
http://www.osdl.org/lab_activities/kernel_tes
Just look around there.
Some more on that history: Larry McVoy on Bitkeeper, kernel development, Linux Torvalds & Bruce Perens
It's still amazing to me that a project as large as Linux was able to be so successfull BEFORE the changes that were made to the development process. It lacked a centralized CVS, coherent bug tracking, automated testing... These are all things I use in the smallest of professional projets.
CVS is an interesting one. I don't really understand his rationale, but Linus says that for Linux development, CVS is not only inadequate, it is bad. Linus has said that if he ever has to quit using Bitkeeper, he'll go back to tarballs, patches and manual version control, because every other available system is worse.
I can certainly see weaknesses in CVS, and for Linux development I can see how the lack of changesets would be problematic, but the notion that manual version control could be better is... startling.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Mandrake 10.0 (which has a RC already) will feature the 2.6 Kernel.
Buy a Nintendo DS Lite
Listen, it's very simple: Subversion wasn't (and still isn't) up scratch. CVS or RCS are so fundamentally broken as to be irrelevant to this discussion.
Wrt. the "must-not-develop-a-competitor" angle: This does not prevent people contributing to Linux. It simply means that they cannot use BK to do it! (If they plan on being able to work on any RCS). You may argue the fairness of such a stipulation in the BK license, but the fact remains: Linus chose BK.
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.
Fedora Core Test 2 is already using 2.6
Just a nit on Subversion's status: it's in beta now, with a release candidate scheduled for tomorrow and the official 1.0 release set for Monday.
how to invest, a novice's guide
[...]
c)reboot test machine and wait 1-3 minutes for it to come up
[...]
step C could be frustrating, is there a quicker way to go about it?
You could making your changes to a User-mode Linux kernel to avoid the reboot. Or running it inside a virtual machine. That way you only have the kernel's boot time, not the main system BIOS, ATA-100 BIOS, SCSI BIOS, etc.
Also, what is the likely() and unlikely() functions you speak of. Google shows a lot of unrelated info.
They're macros that tell the compiler if the expression contained within is likely to be true or false. There's an article about them here. If you've ever seen any code that mentions __builtin_expect, it's the same thing with better names:
ccache - http://ccache.samba.org/
Safe compiler cache if you do "make clean" a lot.
distcc - http://distcc.samba.org/
Simple, fast compilation cluster software.
Both are great.
If you are interested in porting GCC to a new target, then read the porting GCC for dummies document. There are several other accounts floating around that document this process. If you want to get involved with development of GCC internals then read through the GCC internals document. Then download the source code and start looking through it. Start on some small project just to get familiar with how GCC is layed out, how it's built, etc. http://gcc.gnu.org/projects/ has several projects that are relevant; maybe the beginner projects or documentation would be a good place to start. Subscribe to the mailing lists, and ask questions if you don't understand something.