Re: RFC: [2.6 patch] better i386 CPU selection

[Dave Jones <davej@redhat.com>]

On Sat, Sep 13, 2003 at 08:22:12PM +0200, Adrian Bunk wrote:

 > What does a user think on which machines a kernel will run after he 
 > enabled the following options?
 >   - "Athlon/Duron/K7"
 >   - "Generic x86 support"

Currently, as you can only choose one of them, it should be obvious.
With your 'you can choose n number of options' patch, it becomes
confusing why there is a generic option at all.

 > >  > If you read the description of X86_GENERIC it implicitely says a kernel 
 > >  > for a 386 isn't generic.
 > > Apart from using incorrect cache line alignments on P4, an i386 kernel
 > > is no more, no less generic than one compiled with X86_GENERIC
 > plus X86_INTEL_USERCOPY

Sure, but that still doesn't prevent it being used on any system as
a generic kernel.

 > > Incidentally, looking closer you broke this option.
 > > 
 > > +ifdef CONFIG_CPU_VIAC3_2
 > > +  cpuflags-y  := $(call check_gcc,-march=c3,-march=i686)
 > > +endif
 > > 
 > > Its C3_2 becauase it needs -march=c3-2 to use SSE instead of 3dnow
 > > prefetches.  One thing that just occured to me, it may be possible
 > >...
 > 
 > Which gcc does support -march=c3-2 ? gcc 3.3.1 doesn't support it.

the 3.3.2 and 3.4 branches have it.

 > > And "You can select 486/586/686 too" is not an answer. These kernels
 > > need to be small, and errata workarounds should NEVER be compiled out
 > > for exactly this reason.
 > >...
 > Why is a kernel compiled with support for all CPUs necessarily much
 > bigger than a current M386 kernel?

Adding in stuff like cpu specific memory copy routines for example.
There have been several cases where vendors haven't been able to squeeze a
boot kernel onto a CD by 40 or so bytes in the past, leading to a last
minute scavenge to try and reclaim that space. Every little helps.

 > OTOH, why waste space on a 486 for 3DNow! support?

I'm arguing for errata workarounds, not extended support.

		Dave

-- 
 Dave Jones     http://www.codemonkey.org.uk