The Linux kernel project is growing up. New contributors, job delegation, and a source code control system have changed the way the kernel gets hacked. The guy at the center of it all -- Linus Torvalds -- has changed, too. Gone are his days as poster boy for Open Source. He doesn't do Comdex keynotes anymore; he's not on the covers of business magazines; and he rarely gives interviews. No, these days, Linus is all about what he does best: hacking the kernel and keeping a sure and steady hand on the rudder of everyone's favorite project.
LINUX MAGAZINE: Tell us about how your job has evolved in the last few years.
LINUS TORVALDS: One of the things that I wanted to do with Bitkeeper [the source code control system Linus recently adopted] was to see how easy it is to have other people in charge of their own areas. So far, [it's] worked really well with some people. Before, I had to merge patches, and I always did it, but it was still work for me. These days, with those people I know I can work with, it takes a second every week. It's not a big deal anymore. I get an email that says, "Please pull." I pull it. It's done. And that's very convenient.
It works very well within certain subsystems. USB is a perfect example of this. Greg [Kroah-Hartman] just handles all of USB. Nobody even tries to send me USB patches normally. He's the guy. In part, networking and network drivers are the same way.
There is still a problem though. Fundamental patches that aren't clearly in one sub-category still take some work, but there are a few people who handle that, too. Andrew Morton has been really good at memory management, which used to be a major point of contention.
LM: Why was it a point of contention?
LT: There are a lot of people who are interested in memory management. Memory management is just something so fundamental to just about any subsystem. From a user perspective, it's a big deal how you page things up if you're low on memory. But it ends up being a big deal for filesystems, for example, that maintain their journals and have tons of memory for journal data. But then, when the kernel needs memory for other things, the kernel has to have a good way of communicating with the filesystem, saying, "Hey, get rid of that data without the machine coming to a complete halt."
So memory management tends to be caught in the middle of all these different things, which means that it ends up being one of the most complex pieces, and at the same time, the most fundamental. It needs to be 100 percent stable, and at the same time, there are many different people who have different things they want to do with it.
LM: Last year, you switched Linux's virtual memory (VM) code in the midst of a stable release development cycle. That ruffled a lot of feathers. Now that you have some perspective, would you do the same thing again?
TORVALDS: I still think it went about as well as it could go. One of the things about the way it turned out was the fact that it forced people to take a real stand. Without the VM split in 2.4, I don't think anything would have gotten done. That's the reason that I think it was actually good.
LM: Were you thinking that at the time?
TORVALDS: That was the major reason. I mean, everybody had been ragging on the VM system for several months -- this was at 2.4.9. It worked OK, but there were certain loads where it just did not work very well. And there were no solutions in sight. And then Andrea [Arcangeli] came along and said, "If you do this, it fixes the problem." And it did. It broke a lot of stuff, too. It took just two releases to be quite useful again. But it was a big enough change that 50 percent of all kernel developers said, "Hey, that is way out of line. Don't do that." And to some degree that is true, but without [the change] the VM wouldn't have gotten fixed.
And then the Red Hat people stayed at 2.4.9, and suddenly there was this fierce competition going on. The 2.4.9 VM lost every single benchmark out there, so you could point to benchmarks and say, "The 2.4.9 benchmark sucks, and this new kind of radical thing beats the pants off it."
LM: So were you surprised by the reaction at all?
TORVALDS: Some people were more bitter than I expected them to be.
LM: Do you think that we could be in a situation like that again?
TORVALDS: Right now the other issue is the IDE layer, which has a lot of the same issues. The fundamental problem is that most drivers are very independent. There are no connections between different network drivers, which makes it much easier to maintain them. When you make a change to the EEPro driver, you don't want to, by mistake, break two other drivers that just happen to depend on what you've changed. So network drivers rarely have concerns.
In the IDE layer, that's not true. So you have different IDE chipsets assuming different things, and some of them work and some of them don't, and when you try to fix one, you may break another. It's kind of messy.
So during 2.5, I said, "OK, let's go with this radical fairly open rewrite." And again, a lot of people didn't like the instability. In fact, they didn't like it so much that Martin Dalecki, who did the thing, has basically thrown his hands up and said, "OK, I can't take the abuse any more." So that particular rewrite actually ended up going back to the old code just because it takes a certain kind of masochist to actually take the abuse.