Sergey Bugaev, le jeu. 11 mai 2023 18:25:43 +0300, a ecrit: > On Thu, May 11, 2023 at 6:02 PM Samuel Thibault <samuel.thiba...@gnu.org> > wrote: > > See the commit I had just pushed ;) > > Hm, but that doesn't make sense to me. If we want a particular tool -- > Unix uname(1) -- to output "i386" when running i386-gnu software on > x86_64 hardware (and I don't actually know whether we want that, but > at least Linux seems to still return machine = "i686" ),
We do need that. Various configure scripts and whatnot expect "uname -m" to be returning what the distribution is supposed to be using as main arch. > we should do that at some upper layer like maybe in uname(2) > implementation in glibc / proc server. [...] > Why is the exec server even written this way? Surely it already knows > what arch it's built for -- this can be determined at compile time. Not necessarily. On Linux it's *not* the bitness of the program that defines what uname() reports. It's the personality() system call, that changes what the process sees. So that a 32bit program can either see i686 or x86_64 depending on what the caller prepared. In our case we decided to have a 32bit-xor-64bit gnumach, so it's even simpler. > But should not be a reason for the kernel to lie to userspace about > what CPU it is running on, no? Our USER32 kernel only expose 32bit support, so it doesn't seem lying to me. > On the other hand this really raises binary compatibility concerns: if > new, i386-compatible CPU types are added and the kernel starts > returning them, userspace wouldn't recognize them until it is updated > (both in code, and rebuilt) to understand the new types. Yes, and that has been happening for i[3456]86 on Linux, and it posed enough troubles that they stopped doing it at all, and let programs that actually care about the detail of the actual cpu read that from /proc/cpuinfo Samuel
