The long-awaited 2.6 kernel is finally here. The author 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. Some interesting changes took place in the way the Linux kernel is developed and tested. Several key changes have improved overall stability as well as quality.
Improvements in kernel development from 2.4 to 2.6
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Is anyone really interested in learning the details of Linux going through puberty? For whatever it’s worth, grown up operating systems have been using these development techniques for eons — the fact that Linux finally woke up to such obvious development processes isn’t terribly interesting. More interesting is that they still haven’t figured out that they need to be able to take crash dumps by default. (But I’m sure we’ll see in article in several years about how they “discovered” this for the 2.8 series.)
“that helped make 2.6 a better kernel than any that have come before it”
I should hope so…
Looks like they are improving the techniques they use to facilitate so many developers working together. It’s interesting how they said that many different kernel trees where being maintained during the 2.5 cycle. That means that there was more generalization, more developers able to control the code and develop it to meet their own needs.
HI
“More interesting is that they still haven’t figured out that they need to be able to take crash dumps by default.”
why should it?. its only marginally useful. what purposes would it serve that would justify it being enabled by default on the tree. if the distributions require it or you do you can go ahead and do it
Jess
why should it?. its [sic] only marginally useful.
I do kernel development for a living; trust me that it’s much more than “marginally useful”: non-reproducible bugs demand postmortem analysis. As software becomes increasingly mature, the bugs become increasingly non-reproducible. But hey, don’t listen to me: the ongoing lack of kernel crash dumps in Linux is great news for those of us developing competing operating systems…
Hmmmmmrphhhhh…. My soundcard (Audigy) doesn’t work with a 2.6 kernel…
Hi
“But hey, don’t listen to me: the ongoing lack of kernel crash dumps in Linux is great news for those of us developing competing operating systems…”
I understand that you are a competing kernel programming and find crash dumps to be useful. I dont hear any complains from those who are linux kernel programmers.
kgdb is being cleaned up and likely to be merged into the maintree a few weeks later as andrew morton takes over the linux 2.6 tree.
unlike other proprietary versions linux kernel developers have their own trees and user bases. distributions can also enable them by default if they like. so far i have found none of the distributions do it by default which wouldnt be the case if the community finds it useful
can you tell me why this is the case or point out in what way would crash dumps by default benefit the end user in a specific way?
regards
Jess
http://kerneltrap.org/node/view/2410
Anyone have a _summary_ of changes for .2 -> .3?
That is, considering the hacked-up past for development “methodology” as the organization as stated in this article clearly suggests a severe lack of coordination in the past. On the other hand, it’s easy to see why something as small as the Linux kernel (even though it isn’t the simplest thing) took so long to go between the major revisions of 2.4 to 2.6. Really, before they finally started doing this, the development process of Linux was hit or miss. Think how much better and advanced the kernel could have been by this point, if the organization of testing and revision control had been what it is now. Revision control and such isn’t quite as important with a single developer on a single project without others involved, but simply isn’t efficient or practical for something developed by many at the same time, because it requires keeping too much in the head of the single developer in charge of doing the patches (Linus making the final decisions). So, for better or worse, it has largely been the ability of the maintainers of the patches that can be credited with keeping things as stable as they are, but the process previously used was a disaster waiting to spread!
That said, hopefully by going to commonly accepted and practiced methodologies involving proper testing will allow Linux (I refer to the kernel) to advance much faster than it has in the past, with greater stability and predictability.
I’ll give you a really simple, common use for crash dumps: finding out what the system was doing when it crashed. That doesn’t seem like such an odd idea.
A few years ago, we had an IRIX server that would keep crashing randomly. Luckily, IRIX saves the a crash dump when it dies so we could see what processes were active, which was on the processor at the time, how much memory, etc, etc. We used it to narrow down what processes were running every time it crashed, to the point we figured out exactly what was causing the problem: user was doing multiple pipes of a huge data set (5GB, IIRC). We suspect the pipe buffers ate all the available memory, causing the next malloc() in the kernel to fail.
Hi
This could easily be done with kgdb which all of the testing team and kernel developers could use. it is network transparent and can function over uml.
why should end users have this?
regards
Jess
“can function over uml”
Doesn’t help issues that crop up underneath UML. Oh well, like the Sun guy said, “But hey, don’t listen to me: the ongoing lack of kernel crash dumps in Linux is great news for those of us developing competing operating systems…”
Now that is funny. VM/MVS had features 15 years ago that Solaris has just started adding and yet you mock a free kernel. You slay me.
The good thing is that you can probably bring some great skills to Linux when SM finally runs Sun into the ground and you still want to do kernel work.