Mail Archives: djgpp/1997/10/05/11:18:09
On 3 Oct 1997, Ruiter de M wrote:
> OK, let me explain why I ask this. It's not that *I* want to know what
> processor I have (I already know that :), but people or programs
> (config.guess) do. If they use 'uname' they don't want to know it's a
> PC (MS-DOS for OS says enough about that), but also what processor
> is used.
>
> So maybe the maintainer/DJGPP-porter of uname (shellutils? => Eli? I
> can't remember right now) can integrate some extra ID-procedures in
> uname, to make it more useful.
AFAIK, in our case, the config.guess script doesn't really care what
it gets as the CPU part of the system name. DJGPP only runs on the
x86 family of processors, and that is all configuration scripts need
to know. The CPU part is important for those cases where the
operating system's name doesn't identify the configuration
unambigously. For example, Solaris can run on x86 or on Sun's Sparc
processors.
(FWIW, most GNU packages don't even call config.guess as part of the
configure script, at least for now.)
So I don't see any special importance to having `uname' report the CPU
make. If `pc' is too dull, we can always change it to `80x86' (or
even `i[3456789]86', if we feel ambitious ;-). It's just a static
string buried inside some libc function.
Btw, I think it's a bad idea to have the CPUID code incorporated into
`uname' or any library function, because the identification code
issues some tricky and obscure instructions that could fail/crash in
protected mode (like under Windows). IMHO, it is better to produce
dull but satisfactory results than to crash.
(And believe me, I know all about the wounded pride of an owner of a
brand-new Pentium II when `uname' tells them they still have the same
`pc' they did before...)
- Raw text -