[SOLVED] confused over uname options (-i -p -m)

ali.abry · 12-04-2013, 04:42 PM

Hi every body
I just confused over thees options in uname command.
what's the difference between :

Code:

uname -i
uname -p
uname -m

and which one shows that kernel is 32 bit or 64 bit ?

jailbait · 12-04-2013, 05:13 PM

"which one shows that kernel is 32 bit or 64 bit ?"

uname -r

------------------------
Steve Stites

ali.abry · 12-04-2013, 05:18 PM

Quote:

Originally Posted by jailbait

"which one shows that kernel is 32 bit or 64 bit ?"

uname -r

------------------------
Steve Stites

for me it doesn't show the bit number . its just show kernel version

Code:

aliabry@lp:~$ uname -r
3.2.0-56-generic

schneidz · 12-04-2013, 05:46 PM

heres mine:

Code:

[schneidz@hyper ~]$ uname -r
2.6.43.8-1.fc15.x86_64
[schneidz@hyper ~]$ uname -i
x86_64
[schneidz@hyper ~]$ uname -m
x86_64
[schneidz@hyper ~]$ uname -p
x86_64

ali.abry · 12-05-2013, 04:09 AM

Quote:

Originally Posted by schneidz

heres mine:

Code:

[schneidz@hyper ~]$ uname -r
2.6.43.8-1.fc15.x86_64
[schneidz@hyper ~]$ uname -i
x86_64
[schneidz@hyper ~]$ uname -m
x86_64
[schneidz@hyper ~]$ uname -p
x86_64

so whats the difference between thees options ? all of them show one thing .

jpollard · 12-05-2013, 05:04 AM

Quote:

Originally Posted by ali.abry

so whats the difference between thees options ? all of them show one thing .

None. All they do is select different parts of the system version string (uname -a).

It is a Red Hat naming convention that puts the X86-64 or whatever into that string. Some information (like node name) do come from other areas, but most of the info is optional and up to the person configuring the kernel. Cat the file /proc/version for a lot of additional information too. Including the host the kernel was compiled on, when, GCC version used,...

The kernel Makefile by default uses various locations to build up the full string:

Code:

KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)

And the EXTRAVERSION is optional. A lot of the specification can be set at the very beginning of the kernel Makefile. From an older vanilla kernel (3.9.0) the Makefile has:

Code:

VERSION = 3
PATCHLEVEL = 9
SUBLEVEL = 0
EXTRAVERSION =
NAME = Unicycling Gorilla

brianL · 12-05-2013, 05:32 AM

Seems to differ depending on the distro. Here's mine, running Slackware64, 14.1:

Code:

bash-4.2$ uname -r
3.10.17
bash-4.2$ uname -i
AuthenticAMD
bash-4.2$ uname -p
AMD Athlon(tm) 64 X2 Dual Core Processor 5200+
bash-4.2$ uname -m
x86_64

GazL · 12-05-2013, 05:53 AM

And here's mine, also slackware, but self-built kernel.

Code:

gazl@ws1:~$ uname -r
3.12.3-custom
gazl@ws1:~$ uname -i
GenuineIntel
gazl@ws1:~$ uname -p
Intel(R) Core(TM)2 Duo CPU     E7400  @ 2.80GHz
gazl@ws1:~$ uname -m
x86_64

The suffix on uname -r is taken from the kernel's LOCALVERSION= string, specified in .config (in my case '-custom', in yours '-generic'.
Stock Slackware kernels leave that blank (as can be seen on brian's post above).

I suspect schneidz's are all "x86_64" because he's using virtualisation rather than real hardware, so they're really not a good example.

-i and -p will depend on your processor vendor and chip.
-m will give you x86_64 for an "AMD64"/"Intel 64" processor, and is the one you should be checking.

Madhu Desai · 12-05-2013, 06:21 AM

For me, although using real hardware, the result is still same.

Code:

$ uname -ipm
x86_64 x86_64 x86_64

$ uname -r
2.6.32-431.el6.x86_64

$ arch
x86_64

$ lscpu | sed -ne 1,2p -e 10p
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Vendor ID:             GenuineIntel

turtleli · 12-05-2013, 07:42 AM

The -i and -p (and also -o) options aren't in the POSIX standard. Different distros can and do patch these options in different ways to provide some form of output (e.g. Slackware uses info from /proc/cpuinfo), so IMO those options are useless.

uname -m shows the machine architecture the kernel believes it is running on, and according to stackoverflow, if the kernel is 32-bit it will report a 32-bit architecture even if it is running on 64-bit hardware.

schneidz · 12-05-2013, 08:15 AM

Quote:

Originally Posted by GazL

...
I suspect schneidz's are all "x86_64" because he's using virtualisation rather than real hardware, so they're really not a good example...

nope

GazL · 12-05-2013, 08:23 AM

Ahh well, it was a reasonable guess given the "hyper" hostname.

jpollard · 12-05-2013, 10:09 AM

Quote:

Originally Posted by schneidz

nope

definitely. He is using Fedora 15. Here is a full string from Fedora 16:

Code:

$ uname -a
Linux panther 3.6.11-4.fc16.x86_64 #1 SMP Tue Jan 8 20:57:42 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Note the multiple occurrences of x86_64. Each one is a different field extracted by uname.

What is shown is entirely up to the person that compiles the kernel. Different distributions have different standards, so what you get will be different.

jpollard · 12-05-2013, 10:45 AM

Quote:

Originally Posted by schneidz

nope

definitely. He is using Fedora 15. Here is a full string from Fedora 16:

Code:

$ uname -a
Linux panther 3.6.11-4.fc16.x86_64 #1 SMP Tue Jan 8 20:57:42 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Note the multiple occurrences of x86_64. Each one is a different field extracted by uname.

What is shown is entirely up to the person that compiles the kernel. Different distributions have different standards, so what you get will be different.

GazL · 12-05-2013, 12:49 PM

Quote:

Originally Posted by jpollard

What is shown is entirely up to the person that compiles the kernel. Different distributions have different standards, so what you get will be different.

Unlike other distros slackware doesn't meddle with things unnecessarily. We see what upstream intended. I'm not surprised that Fedora shows something else. They mess with everything.