rustup-init.sh: Check for kernel UAPI compatibility on LoongArch #3404
Conversation
xen0n
force-pushed
the
detect-loongarch-uapi
branch
from
93a0846
to
2ea074e
Compare
|
Would it be easier to just check |
I don't have guarantees that a 5.19+ but old-world kernel would not get created and/or deployed to end users. If such guarantee would be given I'd agree this is the simpler way to go. |
Perhaps we can ask Huacai... To me those organizations must keep to use the old-world will only update kernels to a new patch version anyway. They are quite conservative on any upgrading. |
|
Self note: If we were to consider some of the early and experimental new-world distros (that have incompatible glibc symbol versions), the statically-linked helper included won't properly detect them as incompatible. We would need to link to at least one versioned symbol in |
I asked Huacai and the answer is "theoretically this can be done, but ultimately it depends on who's writing code". Obviously, I don't trust the corporate devs making the commercial distros to always do the right thing, so I'd say checking kernel ABI would be more appropriate. (After a couple of years it may finally become evident whether the assumption actually holds, but at that time I'd expect the number of old-world-based developers to shrink enough that this is no longer a concern.) |
And provide friendly diagnostics if a certain widely-deployed but incompatible UAPI flavor (a.k.a. the "old-world" UAPI that's used by several early and/or commercial LoongArch Linux distributions) is detected. The minimalistic probe was crafted by myself, checking for one of the most prominent incompatibilities between the two UAPI flavors: `sizeof(sigset_t)`. The probe binary is small enough to fit in 3 lines of Base64, which is decoded into a temp file and executed for result. The `base64(1)` command is ubiquitous (being provided by coreutils, busybox and probably many others), and only necessary on LoongArch, so we effectively don't lose portability. Other irrelevant errors (e.g. /tmp being noexec) are made non-fatal, because without the check the installer binary will instantly die anyway on an incompatible system. A warning message is printed in case such an error occurs. (The installer binary, being dynamically linked, will die on a system using the other incompatible UAPI, with a confusing error saying the program being executed itself is not found: the actual non-existent path is the ELF interpreter i.e. `ld.so`. Having some error messages in case of this would hopefully reduce the technical support burden for many.)
xen0n
force-pushed
the
detect-loongarch-uapi
branch
from
2ea074e
to
db4b177
Compare
In preparation for the next release which will feature LoongArch support, for a smoother UX in case the user is running an incompatible system (see the commit message & comment for some details).