On Wed, Mar 07, 2007 at 08:40:00AM +0100, Bernd Ernesti wrote:
> On Wed, Mar 07, 2007 at 12:00:51AM +0100, Nicolas Joly wrote:
> > On Tue, Mar 06, 2007 at 07:13:46PM +0100, Bernd Ernesti wrote:
> [..]
> 
> > > The only problem is that it changes amd64 and not i386 too.
> > 
> > i386 does not have the problem; it support Intel CPUs for quite a long
> > time, and display correct CPUs features.
> 
> Hmm, ok not Intel CPUs, but AMD CPUs are still displayed differently on i386:
> 
> cpu0: AMD Dual-Core Opteron or Athlon 64 X2 (686-class)

Ok, but that's another story. For now, i'm just fixing incorrect
display on amd64 port for some CPUs.

> > > IMHO we should move this function into x86.
> > 
> > I'm not sure for the whole function, but indeed some parts could be
> > shared.
> 
> I can't talk about this function because I know to few about it, but
> IMHO all parts which would work on i386 and amd64 should be shared.

I had a look; and in this area, cpu_info structures are currently too
different to share some code. But this can change ...

amd64:
        u_int32_t       ci_feature_flags;
        u_int32_t       ci_signature;
        u_int64_t       ci_tsc_freq;

i386:
        int32_t         ci_cpuid_level;
        uint32_t        ci_signature;    /* X86 cpuid type */
        uint32_t        ci_feature_flags;/* X86 %edx CPUID feature bits */
        uint32_t        ci_feature2_flags;/* X86 %ecx CPUID feature bits */
        uint32_t        ci_feature3_flags;/* X86 extended feature bits */
        uint32_t        ci_padlock_flags;/* VIA PadLock feature bits */
        uint32_t        ci_cpu_class;    /* CPU class */
        uint32_t        ci_brand_id;     /* Intel brand id */
        uint32_t        ci_vendor[4];    /* vendor string */
        uint32_t        ci_cpu_serial[3]; /* PIII serial number */
        uint64_t        ci_tsc_freq;     /* cpu cycles/second */

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.