[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Uname problems
From: |
Wes Hardin |
Subject: |
Uname problems |
Date: |
Wed, 03 Nov 2004 14:43:47 -0600 |
User-agent: |
Mozilla Thunderbird 0.8 (X11/20040917) |
I've found some inconsistencies with GNU uname and Solaris uname, and
since i'm not familiar with any other UNIX platform, I'll just let you
know what i've found and you can sort it all out.
From the GNU uname man page:
-m, --machine
print the machine hardware name
-p, --processor
print the processor type
-i, --hardware-platform
print the hardware platform
GNU uname
(from Gentoo GNU/Linux with coreutils 5.2.1 and SPARC64 kernel 2.4.26 on
an Ultra 60)
mtraining1 ~ # uname --machine
sparc64
mtraining1 ~ # uname --processor
sun4u
mtraining1 ~ # uname --hardware-platform
TI UltraSparc II (BlackBird)
GNU uname
(from Solaris 8 with coreutils 5.2 on an Ultra60)
address@hidden $ uname --machine
sun4u
address@hidden $ uname --processor
sparc
address@hidden $ uname --hardware-platform
SUNW,Ultra-60
Solaris uname
(from same machine)
whardin|cds1 <32> uname -m
sun4u
whardin|cds1 <33> uname -p
sparc
whardin|cds1 <34> uname -i
SUNW,Ultra-60
It seems to me that at a minimum, you'd want as many responses to match
across OSes on the same hardware. On Solaris, both versions of uname
return sun4u for uname -m, but on Linux, sun4u is returned by uname -p.
GNU uname on Linux/SPARC64 returns all the right information, but at
what seems to be the wrong spots. If I was to do uname -p, I'd expect
"TI UltraSparc II (BlackBird)", not "sun4u". If I was to do uname -m,
thats where I'd expect to see "sun4u". And "sparc64", while a good
answer for machine type, is trumped by "sun4u". And uname -i should
return "sparc64", certainly not "TI UltraSparc II (BlackBird)", which
makes very little sense as a hardware platform.
But maybe I'm just crazy...
--
/* wes hardin */ | Help Desk: x6474
address@hidden | Phone: 972-371-6909
address@hidden | Pager: 214-359-1054
UNIX System Admin I | Office: M.112
- Uname problems,
Wes Hardin <=