David Howells put in quite a bit of work on a script,
./scripts/syscall-manage.pl, to simplify the entire process of changing the
system call tables. With this script, it was a simple matter to add, remove,
rename or renumber any system call you liked. The script also would resolve
conflicts, in the event that two repositories renumbered the system calls in
Why did David need to write this patch? Why weren't system calls already fairly
easy to manage? When you make a system call, you add it to a master list, and then
you add it to the system call „tables“, which is where the running kernel looks up
which kernel function corresponds to which system call number. Kernel developers
need to make sure system calls are represented in all relevant spots in the source
tree. Renaming, renumbering and making other changes to system calls involves a
lot of fiddly little details. David's script simply would do everything
of story no problemo hasta la vista.
Arnd Bergmann remarked, „Ah, fun. You had already threatened to add that script in
the past. The implementation of course looks fine, I was just hoping we could
instead eliminate the need for it first.“ But, bowing to necessity, Arnd offered
some technical suggestions for improvements to the patch.
However, Linus Torvalds swooped in at this particular moment, saying:
Ugh, I hate it.
I'm sure the script is all kinds of clever and useful, but I really think the
solution is not this kind of helper script, but simply that we should work at not
having each architecture add new system calls individually in the first place.
IOW, we should look at having just one unified table for new system call numbers,
and aim for the per-architecture ones to be for „legacy numbering“.
Maybe that won't happen, but in the _hope_ that it happens, I really would prefer
that people not work at making scripts for the current nasty situation.
And the portcullis came crashing down.
It's interesting that, instead of accepting this relatively obvious improvement to
the existing situation, Linus would rather leave it broken and ugly, so that
someone someday somewhere might be motivated to do the harder-yet-better fix. And,
it's all the more interesting given how extreme the current problem is. Without
actually being broken, the situation requires developers to put in a tremendous
amount of care and effort into something that David's script could make trivial and
easy. Even for such an obviously „good“ patch, Linus gives thought to the policy
and cultural implications, and the future motivations of other people working in
that region of code.
Note: if you're mentioned above and want to post a response above the comment section, send a message with your response text to email@example.com.