Messages in this thread | | | Date | Mon, 14 Nov 2005 19:23:41 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH 0/13] Time: Generic Timeofday Subsystem (v B10) |
| |
* Andi Kleen <ak@suse.de> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |