* Andi Kleen <[email protected]> wrote:
> My point was basically that there is a lot of feature work going on on
> x86-64 in this area, and that has priority over any "cleanups" like
> this from my side. [...]
i think we are in agreement mostly, but this approach of yours is just
... totally wrong. We are seeing an exponential increase in the 'cost'
of new time features because they are being built ontop of a naive base
that did not anticipate them. HRT was 'coming soon' for how many years -
eight?
just take a look at all the VFS work Al Viro has done and is doing. 90%
"cleanups", in preparation of a small 1000-line (or smaller) real
feature thing. If it were done the other way around, we'd still be at
5-10 poorly integrated filesystems and a poor VFS landscape - not at the
current 50+ filesystems supported by the best VFS on this planet ...
or just take a look at all the work Jens Axboe & co has done in the past
2 years, resurrecting the block IO code from the grave. Jens started at
the basics (replacing bhs with bio's), cleaning up the mess at its root.
Had they started adding pluggable IO schedulers and IO barriers as the
_first_ step, the block IO layer would still be a pain point, instead of
a poster-child.
i could go on with other examples. Networking. Firewall code. The MM.
Driver architecture - and more. x86_64 did get rid of lots of i386
legacies as well, so you are doing it too. Today's cleanliness is the
basis for tomorrow's features, not the other way around. New features
_always_ deform the code's internal structure, and if piled upon each
other without cleanups inbetween then they form a massive, hard to
change and hard to maintain chunk of spaghetti. The time code has been
long overdue for a massive cleanup.
the Linux CPU architecture code is currently where the VFS was 5 years
ago. Lots of consolidation work was done in the past 1-2 years, but both
i386 and x86_64 still have at least 30% of code bloat that does not
truly belong into architecture code. Now we have 25 main architectures,
and every unnecessary unit of complexity gets multiplied by 25!
Suggesting that generalization, common code and cleanups have a lower
priority than features is really ignoring history and common sense.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
