Neil Brown's session on the notion of a core vision for the Linux kernel
started with the idea that Linux has, on the whole, been reasonably
successful. There are three reasons for that success, he said: the
strengths in Linux's Unix history, the GPL, and the development community.
For this talk, he focused mostly on the first of those. According to
Thompson and Ritchie, the design of Unix was based on "the full
exploitation of a carefully selected set of fertile ideas" (this is an idea
that Neil has discussed in
as well). But, Neil said, this "careful selection" was done by
two engineers. Do we have a process in place to scale this selection to
Al Viro jumped in with the claim that Neil had missed one important
component in the success of Unix: those two engineers had taste. Therein
lies the problem for Linux; a lot of the code coming in is tasteless. It's
hard to fix; taste is a hard thing to formalize, and trying to educate
developers in taste is not even encouraged. Any discussion of taste is
seen as unfriendly, no matter how it's done. Paul McKenney pointed out
that there was more than taste involved, though; Unix was also full of
things like gets(), which clearly are not in good taste.
Economics was a big part of why Unix has been so successful for so long.
Mel Gorman suggested that developers should ask themselves if they would
submit their patch to any other operating system. Would it also be
suitable for one of the BSDs? If the answer is "no," that might be a good
indication that taste is lacking. He also said that it's hard to tell
developers that their work lacks taste. It's not like a technical problem
which can be fixed; something without taste often needs to be rethought
from the beginning.
Looking at the design of a patch before its implementation might be one way
to ensure better taste. But, as Ted Ts'o pointed out, that tends not to
work well in the Linux environment. Developers are strongly tuned to code;
they will be suspicious of design documents which appear without an
accompanying implementation. When a document is all there is, it's hard to
tell if the developers are serious enough to see things through.
Linus said that one thing he has been doing in recent times is pushing back
on features which only have one user. Good taste is important, he said,
but it's very hard to explain to developers. But if those developers go
through the process of making their work applicable to multiple groups of
users, they will often learn a lot. One feature which is being held back
for this reason currently is Cleancache,
which hasn't yet found enough users to be put into the kernel.
Proposed new system calls have also been rejected for the same reason. They
must have at least two users, though Linus wondered if that should be
raised to three.
Al cited the proposed the "open by handle"
system call as not showing great taste; it reveals too much information
from within filesystems. It could maybe be made acceptable if the
resulting file descriptor had the O_NOACCESS flag set, so that it
could only be used in system calls like openat(). He indicated
that this idea needed further thought, though.
Linus requested that subsystem maintainers get better at saying "no." If
he has to reject a patch it is, by his reckoning, a failure of the
process. Maintainers especially need to learn how to say "no" to their own
One place where he should have said "no," he said, was the fanotify
patches. Indeed, he should have rejected dnotify and inotify as well.
There comes a point, after two or three failed attempts, where one has to
realized that an idea is just broken. So he will never again accept a file
notification API; anybody proposing one may get a stronger reaction than he
bargained for. Some problems, Linus said, are simply too hard to be
Next: A staging process for ABIs.
to post comments)