lkml.org 
[lkml]   [2002]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: initramfs programs (was [RFC] klibc requirements)
On Thu, 10 Jan 2002, Giacomo Catenazzi wrote:

> It is already difficult to maintain the database of CPU.
> The newer CPUs have name stored directly in CPU and no more
> in kernel :-(

It's worse than you think.
Distinguishing between XP and MP athlon for example needs
capability bit testing. (And some XP's _are_ now multiprocessor
capable, just to confuse the issue some more), so relying on
the cpuid identity string isn't foolproof.
(Also, some implementations allow for this string to be changed,
some folks have it set to "PenguinPowered" and the likes 8-)

> This is a call for help: how to write a table
> CPU - CONFIG_SYMBOL ?
> Now I use Vendor/Name/Family/Stepping/, but
> maybe with Vendor + flags (CPUID flags) the result
> will be more correct?

Asides from the above issues, multiple CPUs have the same
cpuid sometimes, meaning you have to check things like
cache size as well (though most (all?) of these should
end up with the same CONFIG_ option iirc, so this shouldn't
be an issue -- you should check to be sure though)

x86info's identify.c files should give you a fairly
comprehensive guide to the various types.

--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:15    [W:0.609 / U:0.984 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site