# Gentoo patches, coreutils, and uname

## depontius

I just ran into a "platform detection" problem with uname and some software at work.  They use "uname -p" to figure out 64-bitness of the machine.  Of course IMHO they should be using "uname -m" instead, but I may have a snowball's chance of getting that changed, though I'm trying.

In the meantime, a company internal installation based on RedHat Enterprise Linux 4.6 returns "x86_64" for "-m", "-p", and "-i" options of uname.  My Gentoo machine returns "x86_64", "Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz", and "GenuineIntel" in that same circumstance.  My initial reaction was that the company had done some stupid patching, besides using "uname -p" instead of "uname -m".  But then I looked a little further and see that Gentoo patches uname to use /proc/cpuinfo, if available.  The strings I'm questioning are right there in "vendor_id" and "model name".  So it appears that perhaps Gentoo is to "blame" for this one, though it seems to me that the Gentoo uname acts more informatively than upstream.

Does anyone have any comment on this?

I'm curious on the history of the issue.

In the meantime, I hand-patched elsewhere in uname.c to return things the same way as is expected by our platform detection logic.

----------

## loki_val

```
USE=vanilla emerge -1 coreutils
```

 gives you upstream behaviour w.r.t. uname. But that will not solve your problem:

 *Quote:*   

> loki gambas # uname -m
> 
> x86_64
> 
> loki gambas # uname -p
> ...

 as opposed to USE=-vanilla behaviour: *Quote:*   

> loki gambas # uname -m
> 
> x86_64
> 
> loki gambas # uname -p
> ...

 I suspect that this may simply be a matter of behaviour having changed between coreutils-5.2.1, which is used in RHEL 4.6 and coreutils 7.4, which is the version which is currently used in ~arch Gentoo.

----------

## depontius

It wouldn't surprise me if you're right on that.  Are you also saying that the Gentoo patches against stable (7.1?) coreutils simply give what will be the standard behavior on the new upstream (7.4?) coreutils?

The obvious fix is for the developers to use "uname -m" for this particular platform determination.  There's no way they'll do that, just because I'm being pedantic about it.  But I may be able to convince them that our customers may have problems because of this, and that my solution is more portable.  This would be especially true if indeed the Gentoo patch matches future upstream behavior.

----------

## loki_val

 *depontius wrote:*   

> It wouldn't surprise me if you're right on that.  Are you also saying that the Gentoo patches against stable (7.1?) coreutils simply give what will be the standard behavior on the new upstream (7.4?) coreutils?

  Whay I'm saying is this: The gentoo patches to coreutils only serve to give some meaningful contents to the -p and -i switches to coreutils. You can test coreutils without gentoo patches by doing 

```
USE=vanilla emerge -1 coreutils
```

The gentoo patches to coreutils have been in use for some time now, so they are applied to all versions of coreutils.

----------

## depontius

I agree with the usefulness of the patches, I was more wondering if they were headed upstream.  Apparently the patches RedHat applies make all 3 return the same "x86_64".  The Gentoo patches at least return a little more information.  In my case, it's just that it's different from what RedHat does, and different from what the software I'm using expects.

Regardless, the software I'm using will break on anything that doesn't feature RedHat-like behavior.  If they use "uname -m" instead of "uname -p", their software will be fully portable.  As in most industrial/commercial/corporate situations, "works with the supported platform" trumps "done properly".  I've patched my copy of coreutils to act like RedHat, but I much prefer the Gentoo behavior.  Saying the Gentoo behavior is going upstream would give me additional ammunition in asking them to change to the more correct "uname -m".

----------

## loki_val

 *depontius wrote:*   

> I agree with the usefulness of the patches, I was more wondering if they were headed upstream.  Apparently the patches RedHat applies make all 3 return the same "x86_64".  The Gentoo patches at least return a little more information.  In my case, it's just that it's different from what RedHat does, and different from what the software I'm using expects.

 I assumed you had read the patch in question, allow me to quote: *003_all_coreutils-gentoo-uname.patch wrote:*   

> On linux platforms, grok /proc/cpuinfo for the CPU/vendor info.
> 
> Prob not suitable for upstream seeing as how it's 100% linux-specific
> 
> http://lists.gnu.org/archive/html/bug-coreutils/2005-09/msg00063.html
> ...

 

But note that the uname -p and -i will still return != x86_64 on any other platform than RHEL.

----------

## depontius

Oops, I skipped the comments and went right to the code.  Sorry about that, but I can still hammer on the non-portability - and hope they care.

----------

## depontius

Thanks for your assistance, loki_val.  The developers actually changed the platform detection code to use "uname -m".  I suspect it helped knowing that "uname -p" was a RedHat patch of the upstream also, perhaps subject to change in the future, and that "uname -m" was the safe way to do this, even for RedHat.

----------

