Re: [PATCH 0/13] Time: Generic Timeofday Subsystem (v B10)

[Ingo Molnar]

* Andi Kleen <ak@xxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/