[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: uname -p



Michel,

Beside Ethan's answer and opinion given to your question (which I support
totally since I have lots of legacy makefile from SunOS myself), I'll just
describe what 'info uname' under Linux will return:

'-m'
'--machine'
    Print the machine (hardware) type.

which should probably be something like 'powermac', 'chrp', or 'prep' in the
case of a powerpc machine.

'-p'
'--processor'
    Print the machine's processor type.

which should in theory be 'ppc' for any PowerPC architecture, and x86 on any
Intel {3,4,5,6}86 (I could imagine having the processor type given more
precisely on intel, since it's easier to mask the first digit to find the
ISA with a script in that particular case: *86 or ?86. That is just
convenient.)


I wrote in a previous email to express my surprise about getting a
'-powerpc' extension at the end of the version returned by the command
'uname -r' with a pre-compiled kernel image, which I think should not be
done. I understand now why such a decision was made, as it can't be
determine at runtime by entering a simple 'uname -p'.

IMHO, uname is not correctly implemented under Linux (version-wise for ports
and machine/processor-wise in general.) According to your comment, it seems
to go beyond the PowerPC architecture unfortunately for the latter, as you
mentioned that you get 'unknown' running on x86.

Being new around here, I wonder if this shouldn't be filed as a bug?
Thanks for your feedback,


Laurent


on 9/14/01 4:39 AM, Ethan Benson at erbenson@alaska.net wrote:

> On Fri, Sep 14, 2001 at 01:15:15PM +0200, Michel Dänzer wrote:
>> Laurent de Segur wrote:
>> 
>>> Entering 'uname -p' should return 'ppc' but returns 'unknow' running
>>> 2.4.8-powerpc with debian/woody.
>> 
>> What makes you think it should return ppc (uname -m does) ?
>> 
>> I just tried it on a sparc64 and an i686 system and both returned unknown as
>> well.
> 
> well lets see what SunOS does/says on the matter...
> 
> erbenson@terminator ~$ uname -m
> sun4m
> erbenson@terminator ~$ uname -p
> sparc
> erbenson@terminator ~$ uname -a
> SunOS terminator 5.8 Generic_108528-09 sun4m sparc SUNW,SPARCstation-20
> erbenson@terminator ~$
> 
> from the SunOS uname man page (which is much more informative then GNU's)
> 
> 
> -m    Prints the machine hardware name (class). Use of  this
> option is discouraged; use uname -p instead. See NOTES
> section below.
> 
> [...]
> 
> -p    Prints the current host's ISA or processor type.
> 
> [...]
> 
> NOTES
> Independent software vendors (ISVs) and others who  need  to
> determine  detailed characteristics of the platform on which
> their software is either being installed or executed  should
> use the uname command.
> 
> To determine the operating system name  and  release  level,
> use  uname  -sr.  To  determine  only  the  operating system
> release level, use uname -r. Notice  that  operating  system
> release  levels are not guaranteed to be in x.y format (such
> as 5.3, 5.4, 5.5, and so forth); future releases could be in
> the  x.y.z  format  (such  as  5.3.1,  5.3.2,  5.4.1, and so
> forth).
> 
> In SunOS 4.x releases, the arch(1) command was often used to
> obtain  information  similar  to  that obtained by using the
> uname command. The arch(1) command output "sun4"  was  often
> incorrectly  interpreted to signify a SunOS SPARC system. If
> hardware platform information is desired, use uname -sp.
> 
> The arch -k and uname -m commands return equivalent  values;
> however,  the use of either of these commands by third party
> programs is discouraged, as is the use of the  arch  command
> in  general.  To  determine  the  machine's  Instruction Set
> Architecture (ISA or processor type), use uname with the  -p
> option.
> 
> 
> my interpretation of this is that linux is wrong, -m should be giving
> more information about the machine itself, not just the processor, for
> the processor you should be using uname -p (which on linux is
> useless).
> 
> otoh SunOS is certainly not any great role model on how to do things
> correctly IMO, but its a more informative reference to look at then
> the GNU uname man page. 



Reply to: