* Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:

quoted text
> On Mon, 08 Sep 2008 21:02:49 +0200, Ingo Molnar said:
> 
> > ... and so on it goes with this argument. Everyone has a different 
> > target audience and there's no firm limit. Maybe what makes more sense 
> > is to have some sort of time dependency:
> > 
> >   support all x86 CPUs released in the last year
> >   support all x86 CPUs released in the past 5 years
> >   support all x86 CPUs released in the past 10 years
> >   support all x86 CPUs released ever
> >   [ ... or configure a specific model ]
> > 
> > and people/distributions would use _those_ switches. That means we could 
> > continuously tweak those targets, as systems become obsolete and new 
> > CPUs arrive.
> 
> That's just *asking* for flame mail if somebody builds a kernel for a 
> system that's 4 year 9 months old, and he builds a kernel 6 months 
> later, and it fails to boot because the CPU is now 3 months out and 
> we've deprecated it...

yeah, in terms of precision of the definition it's certainly more 
towards the 'vague' end of the spectrum. OTOH, we do change our defaults 
slowly but surely to match the hardware. So this would give a practical 
definition. If someone _does_ complain legitimately, it doesnt cost us 
much to revert a tweak and delay it some more.

So the idea is to have some sort of independent platform, instead of the 
current practice of distros like Debian chosing pretty much random 
options. No strong opinion though. We can cover 90% of the real 
advantages via dynamic methods, it's quite rare that we have to make 
hard .config choices.

Pretty much the only hardcoded aspect that hurts in practice is the 
cache alignment parameter - all the rest is either dynamic already or 
insignificant. Ever since distros have discovered 
CONFIG_CC_OPTIMIZE_FOR_SIZE=y, even the various compiler optimization 
parameters have less of a role. We just have to wait a year or two for 
P4's to not matter that much anymore, then we can do generic kernels 
with 64 byte alignment and cmov, that will just work almost everywhere 
rather optimally.

	Ingo
--
unsubscribe notice
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/