The performance benefit is trivial, and the improvement to
maintainability is even less.
Contributions to the kernel take forms other than just code. I'm
contributing in this very instance by putting the argument against
removal of code. Once removed it'll be much harder to re-insert than to
repair in-situ.
I don't know when. Are you disputing that it ever did? I think it's a
given that once it worked.
Fools believe that code is the only acceptable offering, and you, by
reputation, are not a fool. There are plenty of examples where
suggestions made on list have value far exceeding a lot of the code.
For that matter, some of the code that's offered is crap. For that
matter, good contributed code too often (and in some cases famously)
gets ignored or rejected for reasons of ego. You diminish yourself by
implying that code is the only thing that matters, and present the
impression that you know little about good development practice, in
which design effort exceeds that of coding. I do not believe you are a
cowboy; stop talking like one.
Look at the merits of iBCS2 support. Is it desirable? Yes. Is it
useful to remove what support remains? Not particularly. Does it
improve performance? Trivially; almost immeasurably. Does it improve
clarity? No. Does the code serve any useful purpose? Yes, by acting
as a reminder of work still be done. It's like the /* XXX */ comments
that are widely sprinkled through the system, only more concrete. The
benefits of removing it do not outweigh the benefits of leaving it.
--
