The closing slot in the first day of the 2011 Kernel Summit was dedicated
the traditional session where Linus Torvalds and Andrew Morton talk about
the development process and how things can be improved. There were not
large numbers of complaints to be heard this time around.
Linus started by saying that he is happy; there is no subsystem that he
wants to slam this year. In his mind, the biggest problem we have is the
increase in kernel complexity. We have, he said, been adding new features
and clever code too aggressively. The memory management subsystem stands
out, but he is confident that it is happening throughout the kernel. But,
at least, he does not see any serious process issues like we have had in
previous years. There are no big conflicts, and his laptop hasn't broken
in a while.
Maintainers, he said, should say "no" more often. Once upon a time it was
Linus's job to do that, but he really can't enforce it anymore. The number
of patches that he merges directly is quite small; that leaves him with the
option of taking what he has been given or rejecting an entire pull request
from a subsystem maintainer. It's those maintainers who have to take on
the "say no" responsibility now. There does not need to be any specific
reason to turn down a patch, he said; what is really needed is a reason to
accept a patch.
Dave Airlie complained about the number of patches that break the kernel
and make bisection of problems during the merge window impossible. Linus
acknowledges the problem, saying that he wishes every tree that feeds into
the kernel would be bisectable, but that is never going to happen. There
was some talk of fixing up git so that bisection would stop between merges
into the mainline (instead of in the middle of them) when possible. Trees
are usually more stable when they are pushed to Linus, so that approach
should make bisection a bit more reliable. That is especially important
for problem reporters who are not kernel developers and who cannot be
expected to cope with kernels that explode in the middle of a bisection
Going back to saying "no," Ingo said that it can often be hard to make a
"no" stick. Sometimes, a developer of a rejected patch will rewrite it to
make it applicable to a different subsystem, then merge it through a more
agreeable maintainer. He would like a tag ("Rejected-by" or some such)
that developers would have to apply to patches after they had been turned
down by one subsystem. Linus made the reasonable observation that
developers might show a certain lack of diligence when it came to adding
those tags, and that the exercise wasn't worth the effort. No system is
perfect, he said, and we shouldn't aim for perfection in our processes.
Arnd Bergmann asked if we were reaching a point where there is support for
too many architectures in the kernel. There are two more poised for the
3.2 merge window, and at least four in the works thereafter. Linus said
that architectures are sort of like filesystems; we have a lot of them but
few of them are heavily used. The cost of the other architectures is not
high, though; the quality of the code has been fairly good and they do not
add complexity in general.
Dave Airlie asked about the idea of merging more user-space code into the
kernel. Linus said that he is not against it; it has been good for
projects like perf. Sometimes people try to take it too far, but that is
normal; it's a balancing act like any other. He is not convinced about
QEMU, which is an idea that has been floated a few times.
And that is where the first day of the 2011 Kernel Summit wound down, with
several developers heard to be muttering about beer.
to post comments)