I mentioned this briefly on cygwin-patches during the review of the fix for a deadlock when running under emulation on ARM64 hosts, but I wanted to discuss it more thoroughly here now that that is merged.
It seems like it would be useful, perhaps for stats tracking purposes like MSYS2 does [1], to indicate when Cygwin is running under emulation in uname. When i686 Cygwin was supported, there was a `-WOW64` tag appended to the sysname field (uname -s) when it was running under WOW64, so it seems to make sense to me to do something similar (say, appending `-ARM64`). There was some concern that appending -ARM64 might cause confusion with a future native ARM64 version of Cygwin [2], but technically it would not because the architecture of Cygwin is reported in the "machine" field of uname (uname -m), while my proposal is to append the host architecture to the sysname field (uname -s), only when it doesn't match the architecture of Cygwin iteself. I'm prototyping this based on Cygwin 3.3.6, because still supporting i686 results in a more complete test matrix (I don't want to come up with something that isn't extensible if Microsoft ever adds something new to the matrix): Cygwin Host Suffix i686 i686 (N/A) i686 x86_64 -WOW64-x64 (or omit arch to match existing?) i686 ARM64 -WOW64-ARM64 x86_64 x86_64 (N/A) x86_64 ARM64 -ARM64 (x86_64-on-ARM64 is not considered WOW64 by MS) Theoretical: ARM64 ARM64 (N/A) Not worth worrying about: ARM ARM64 -WOW64-ARM (?) I'm mostly just curious how the algorithm would act there, there should be *zero* interest in actually porting Cygwin to 32-bit ARM, MS just dropped support for 32-bit ARM binaries on ARM64 in Windows 11 24H2. Thoughts? [1]: https://github.com/msys2/MSYS2-packages/discussions/2832 [2]: https://github.com/msys2/msys2-runtime/issues/238#issuecomment-2481438646 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
