Bug 446557

Created attachment 305433 [details]
coreutils-4.5.3-sysinfo-sh-linux.patch

Thanks for the patch, in the case of such trivial changw it is not really
necessary. But I'm not very familiar with Super-H architecture. Could you please
give me some background why is this change necessary? 

Or better said - patch for ix86 uname in fedora is simplification for scripts
(and never got to upstream coreutils). As you have many shXY possible uname
returns(sh, sh3, sh4, sh4a) and Fedora doesn't support shXY architecture yet,
I'm not sure if this change is reasonable. IMHO could be kept outside of Fedora
until shXY architecture will be oficially supported. 

Thanks for comment.

Sorry. I don't know any background of this patch becasuse 
I'm not an author of it.

Could you show me an example of script which needs to patch ix86 uname ?
I'll check whether it also needs on sh platform.
(I'm planning to make sh platform to be secondary architecture.)

ix86 uname script usage could be following - instead of usage i386|i586|i686)
check in script, you could easily use i386. Could be useful in some cases. It is
just unification. I agree that such unification is justified even for SuperH
architecture(as there is existing precedens in Fedora). I have seen some SuperH
architecture scripts and they often use constructs sh|sh3|sh4|sh4a) for uname.
Therefore maybe replacement by sh would be more universal, but I'm not sure
about the full compatibility. It has to be considered... 

Anyway, that patch imho has no chance to get into upstream coreutils (and should
be kept distro specific) . So It could be included into existing uname patch -
as it seems to be useful for sh support as secondary architecture. 

I can understand this unification logically, but... who is the real user?
Hmm..., coreutils-4.5.3-sysinfo.patch has been there from the beginning
of RedHat's coreutils package (RHL9). 
Maybe, it comes from Mandrake Linux's package.
And since the patch has been there for more than 5 years, 
there will be many unknown user(script) relay on this unification.

Oh, some spec files like postgresql.spec also use it.
(Hmm, they should use rpmmacro instead, I think.)

On the other side, I chased the history of coreutils-4.5.3-sysinfo-sh-linux.patch
and found that it first appeared Fedora7/SH.
(You can get it from http://ms-n.org/sh-linux/)

The company which is offering unofficial Fedora/SH
sells SH4a CPU board(SH2007) with FedoraCore6/SH on their product. 
FC6/SH doesn't contain coreutils-4.5.3-sysinfo-sh-linux.patch.

Now, they offer updated kernel [1] which has patched uname
system call to return sh4 even on sh4a CPU.

From these history, I suppose coreutils-4.5.3-sysinfo-sh-linux.patch
is not enough for THEIR requirements.
I agree that only sh4 and sh4a unification is not enough 
for certain requirement as you say.

OK. I withdraw the coreutils-4.5.3-sysinfo-sh-linux.patch .
I was wanting to leave these discussion log somewhere because
their(http://www.sh-linux.org/) patches don't have any 
documentation .

Thank you.


[1] http://www.sh-linux.org/
linux kernel source for SH-2007,SH-2004,SH-2002 and root file systems

--- linux-2.6.24.3/include/asm-sh/bugs.h    2008-02-26 09:20:20.000000000 +0900
+++ linux-sh-2.6.24.3/include/asm-sh/bugs.h 2008-03-05 11:41:48.000000000 +0900
@@ -27,7 +27,9 @@
                break;
        case CPU_SH7206:
                *p++ = '2';
+#if 000
                *p++ = 'a';
+#endif
                break;
        case CPU_SH7705 ... CPU_SH7729:
                *p++ = '3';
@@ -37,7 +39,9 @@
                break;
        case CPU_SH7770 ... CPU_SHX3:
                *p++ = '4';
+#if 000
                *p++ = 'a';
+#endif
                break;
        case CPU_SH7343 ... CPU_SH7722:
                *p++ = '4';

Aah, I forgot that bugzilla completely, as I see they/you have fix by SH kernel,
I guess this bugzilla could be closed NOTABUG - as Fedora doesn't support SH
architecture and there is already existing kernel fix for SH arch. Feel free to
reopen the bugzilla in the case that the problem will need change in uname in
future. Anyway such things are better done by kernel and not by coreutils
workaround.

As someone just pointed this out to me yesterday, this comment is a bit late. Anyways..

Any patch that pretends that sh4a and sh4 are the same thing is fundamentally broken. uname returns sh4a instead of sh4 precisely because they are different architectures. gcc and binutils both have different targets for sh4a over sh4, and these generate completely different code. While sh4 application code can generally be run on sh4a, sh4a code can not run on sh4. At the same time, neither sh4 nor sh4a generated code will run on sh4al-dsp with the default configurations. These all have different unames for a good reason, not just because I was bored and wanted to break userspace applications from the kernel.

If userspace applications are papering over this or lamely hacking the kernel to pretend the problem doesn't exist, they are just going to end up breaking. Any distribution that engages in this stupidity is fundamentally broken.

If a build script bails out because it can't recognize the uname, that needs to be fixed, not the uname!