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 should do that at some upper layer like maybe in uname(2) implementation in glibc / proc server. But should not be a reason for the kernel to lie to userspace about what CPU it is running on, no? 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. 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. This is not about network transparency (exec server running on one arch, the task being exec'ed over on another) either: the function makes no attempt to check the task's host; it just checks mach_host_self (). Sergey
