coreutils uname-2 patch

Bryan Kadzban bryan at
Sat Oct 30 13:36:35 PDT 2004

Robert Connolly wrote:
> uname-2 gives me:
> i686 athlon i386 GNU/Linux
> This uname-3 gives me:
> i686 AMD Duron(tm) Processor AuthenticAMD GNU/Linux
> uname-3 is more accurate for my system, no idea about others. If I
> remember correctly there is a problem with using /proc/cpuinfo
> vendor_id and model name with some architectures, but I'm not sure.

More accurate, yes, but you can't very well tell gcc to optimize for
"-march=AMD Duron(tm) Processor", right?  It won't exactly recognize
that option...

In that respect, uname-2 is better.  (Its output is also more easily
machine-parsed, since it can be split on whitespace.)  IIRC, that was
the whole point of the uname patch -- to get it to print something that
gcc would take as an option to -march or -mcpu.  I don't believe it was
supposed to regurgitate /proc/cpuinfo, because /proc/cpuinfo didn't
contain anything that gcc could use.

Of course, I may not remember correctly, either...

(BTW: Is anybody else getting two copies of these messages in wherever
they filter -hackers traffic to, or is my mail server screwing something
up?  This seems to happen every time a message gets sent to both
-hackers and some other list, but the other list is usually lfs-dev, and
I'm subscribed to that.  Since nobody else has complained, I thought it
was my mail server messing up when it saw 2 copies of one message, but
I'm not so sure about that anymore.  Especially since the automatically
generated sig (unsubscribe info, etc.) is different between the copies.)

More information about the hlfs-dev mailing list