Red Hat Bugzilla – Full Text Bug Listing
|Summary:||change "uname -i" to returen sh4,not sh4a,on sh4a CPU. (Super-H architecture)|
|Product:||[Fedora] Fedora||Reporter:||CHIKAMA Masaki <masaki.chikama>|
|Component:||coreutils||Assignee:||Ondrej Vasik <ovasik>|
|Status:||CLOSED NOTABUG||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-07-10 17:02:17 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description CHIKAMA Masaki 2008-05-14 23:26:43 EDT
Description of problem: This patche is forward ported for coreutils-6.10 getting from http://www.sh-linux.org/ . Patching to 'uname' over coreutils-4.5.3-sysinfo.patch in package, uname -i (--hardware-platform) returns sh4 on sh4a CPU board insted of sh4a. --- src/uname.c.orig 2007-08-21 10:23:22.000000000 +0900 +++ src/uname.c 2007-08-21 11:07:08.000000000 +0900 @@ -330,6 +330,8 @@ main (int argc, char **argv) element = u.machine; if(strlen(element)==4 && element=='i' && element=='8' && lement=='6') element='3'; + else if(strlen(element)==4 && element=='s' && element=='h' && lement=='a') + element=0; } #endif #ifdef UNAME_HARDWARE_PLATFORM
Comment 1 CHIKAMA Masaki 2008-05-14 23:26:43 EDT
Created attachment 305433 [details] coreutils-4.5.3-sysinfo-sh-linux.patch
Comment 2 Ondrej Vasik 2008-05-19 06:33:42 EDT
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?
Comment 3 Ondrej Vasik 2008-05-19 07:02:02 EDT
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.
Comment 4 CHIKAMA Masaki 2008-05-19 22:50:20 EDT
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.)
Comment 5 Ondrej Vasik 2008-05-20 05:45:29 EDT
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.
Comment 6 CHIKAMA Masaki 2008-05-20 21:16:08 EDT
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  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.  http://www.sh-linux.org/ linux kernel source for SH-2007,SH-2004,SH-2002 and root file systems --- linux-188.8.131.52/include/asm-sh/bugs.h 2008-02-26 09:20:20.000000000 +0900 +++ linux-sh-184.108.40.206/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';
Comment 7 Ondrej Vasik 2008-07-10 17:02:17 EDT
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.
Comment 8 Paul Mundt 2009-04-24 00:39:53 EDT
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!