bug#7991: bug in uname (?)

[Eric Blake]

[re-adding the list]

On 02/05/2011 06:23 PM, Noel Kuntze wrote:
>> Look at 'man 2 uname'.  On Linux, the uname.release version contains a
>> numeric string.  The uname.version field is not documented as to it's
>> contents, but POSIX merely requires that release and version together
>> identify the operating system kernel.  As confusing as it may be, this
>> behavior is a kernel choice, and coreutils uname(1) has no control over
>> it.  Coreutils is accurately reporting what the kernel told it.
>>
> 
> Hi,
> 
> OK, i understood that.
> However although i run several different Linuxes i didn't use uname on
> any other than Debian.
> To "fix" this bug, one should really talk to the developers of the
> different distributions.

The different Linux distros all use the same uname(2) behavior of the
kernel.  You only need patch the kernel to swap those two fields, but
given historical compatibility, you have a very hard battle in front of
you for getting such a patch to be approved.

You're better off learning to live with the fields as currently defined
by the kernel, in spite of what you feel is an apparent naming confusion.

> This "bug" (i'll call it "bug" in the future, because "weird behaviour
> of the Kernel" is just too long) nearly got me a worse mark (we wrote a
> test about Debian Linux and the last task was to write down the kernel
> version....).

Again, it's not a bug in coreutils, but a feature of your kernel's
uname(2) implementation.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature