LWN has been reporting on the Linux and free software community for well
over five years now, but, during that time, we've never gotten around to
interviewing Linus Torvalds, the creator and maintainer of the Linux
kernel. That oversight has now been rectified. In the following
interview, Linus talks about 2.5, 2.6, and 2.7, SCO, and how the kernel
development process works.
What are, in your opinion, the most significant accomplishments from the
2.5 development series?
There's a number of them, and the ones I think are most important others
may not find as interesting. I personally tend to find "infrastructure"
things more important than adding particular drivers support, for example,
even though to most _users_ the actual drivers are often more important.
During 2.5.x, the things I thought were most noticeable are a nicer and
better VM subsystem, a better block IO layer, and the improved threading
support. All of them do help performance in various circumstances, but
more importantly (to me) they were all fairly central cleanups and help
keep the code maintainable.
Any regrets or things you wish had come out differently in 2.5?
Hey, I always wish we'd do stable releases more often, and I always end up
ignoring my own wish and go for "more changes". It makes the release
process a lot harder (more things have changed results in more
verification and debugging effort), but it does make development more
Looking forward to 2.7, do you have any particular goals in mind for that
No, I seldom do. In 2.5.x, we fixed the things I was worried about and
that I wanted fixed.
But inevitably, new needs and uses will come up, and I'm not worried about
running out of stuff to do. I just don't plan much ahead, I much prefer to
take a reactionary stance and see what people actually complain and care
about, rather than having a "5-year plan".
Do you have any particular expectations or hopes for the upcoming kernel
summit in Ottawa?
To me, the biggest thing is to hear what people are working on or
interested in, and get together to just discuss stuff under reasonably
organized circumstances. For example, I bet I'll have more of a notion of
what people are holding back for 2.7.x..
It took the better part of a year - after 2.4.0 - for the 2.4 series to
stabilize sufficiently for the 2.5 fork to happen. Do you foresee doing
anything differently to stabilize 2.6 more quickly?
It's always hard to tell. One big problem for the 2.4.x series was the VM,
and I think we're _already_ in better shape in 2.5.x than we ever were in
2.4.x. So I'm pretty optimistic, but it's always hard to anticipate
everything that pops up when a lot of new people start moving over from
2.4.x to 2.6.x.
Over the course of 2.5, a number of developers, some of whom have
contributed useful stuff, bowed out of the kernel project after facing too
much criticism that was too harsh. Do you think this is a "if you can't
stand the heat, get out of the kitchen" sort of situation, or could the
process perhaps change to be a little more friendly?
I do believe that the kernel mailing list has become too acerbic at times.
It can be amusing to read the flame wars if you take them the right way,
but not everybody is willing or able to stand back and enjoy the
fireworks. It's something I worry about - it tends to be always easier to
criticise than to actually fix things.
I'll see what I can do about it, if anything.
There have been complaints that recent development has been strongly
oriented toward large-system scalability at the expense of the rest of us
with "normal" systems. Over the longer term, however, a high priority has
been placed on not allowing support for high-end systems to compromise
performance for everybody else. How do you feel about the balance between
the kernel's support for large and small systems? Does anything need to be
done to ensure scalability to the low end?
I think the drive toward "sexy" systems (lots of power, lots of CPU's,
tons of memory, etc) is a fairly natural one, and it's something that gets
attention, and I think that's also why people see that development more.
And yes, scalability has improved a lot, but at the same time you should
realize that 99% of all Linux development is still done on basic desktop
machines. So most developers still care mostly about that kind of
hardware, and so while the "big iron" thing gets most attention and is
most visible, it's not where most of the action _really_ is.
I personally, for example, always just work with a "high end desktop"
system, expecting that what is high end today will be pretty much regular
in another year or two.
In many ways, the kernel development process appears to be working better
than it ever has. The flow of patches into the mainline is astounding, and
most of the major developers seem to be relatively happy. Things appeared
rather rougher at the beginning of 2.5; to what do you attribute the
improvement? Is it all due to BitKeeper, or are there other things going
I definitely think BitKeeper helped, but on the whole people are always
happier in development kernels than they are when you have to be careful.
So expect some grumbling during 2.6.x when developer frustrations mount,
when they can't just go wild.
SCO has finally fingered some specific contributions to the kernel as, they
say, infringing on their rights. Do you think there's a chance that things
like RCU and JFS will have to come out before 2.6 can be released? How do
you think you might respond if SCO demands their removal?
I don't think it's likely, especially since everything that SCO has
fingered as being stuff they object to, they don't actually seem to have
any IP rights claim over. They're all stuff written by IBM (or Sequent,
which was bought by IBM), and everything looks very much above board as
far as IBM goes.
I'd find it very unlikely that IBM had given exclusive licenses to SCO for
the thing, especially as IBM apparently used some of the same technology
for other projects earlier (ie OS/2). So from what I can tell, SCO really
doesn't have a case - at least on the IP side of things.
Whether SCO has a case on the contract side, I just don't know. I'd be
surprised. But I don't even have to care, since any contractual issues are
clearly between IBM and SCO, and have nothing to do with me or the kernel
(and contract law is a whole different area from IP rights, so SCO's
blathering about Linux not respecting IP rights seems to be just a rabid
rat frothing at the mouth, as far as I can see).
Do you foresee any changes to the kernel development process in the future
to avoid the possibility of proprietary code being incorporated?
Hey, I claim that open source is a lot safer than proprietary code bases:
people have full visibility in what goes in, and we can go back through
archives etc to see who did what. In other words, we already _have_ the
process in place to make sure that people don't try to misuse IP rights.
You've just announced a move over to OSDL, to work full-time on the
kernel. Do you have any great plans for your extra time?
I've never had problems with "extra time". As far as I know, "extra time"
as a concept is right up there with Santa Claus and the Tooth Fairy.
Recently you have been peppering the kernel with __user annotations which
can be used by the "sparse" tool to find improper use of user-space
pointers. I've always wondered why the kernel doesn't simply define a
"userptr" type which would allow mistakes to be caught by the compiler?
The problem with a "userptr" type is that there is not just _one_ type of
user pointer, there are hundreds. User pointer to _what_? You need a bit
outside/perpendicular the regular type system, to say it's a "user pointer
to a 'struct stat'".
I mentioned that to some gcc people, and nothing ever appeared, so I
decided to do it myself.
Would it not make sense to make a similar distinction between physical and
kernel virtual addresses?
It could certainly be done, with the tool I already wrote. We've never
really had that as a major problem, though. Usually we use "unsigned
long" for physical addresses (or things like "page frame numbers", ie they
are an index to physical pages, not a whole address). Those have never
been directly dereferencable, so we've not had the same kind of "buggy
code works by mistake" situation that we've had with user pointers.
Thank you, Linus, for taking the time to answer these questions.
to post comments)