Hi, On 2020-04-26 16:37, Julien Cristau wrote: > On Sun, Feb 16, 2020 at 04:27:11PM +0000, Ben Hutchings wrote: > > This was discussed on IRC with Julien Cristau, but unfortunately I > > didn't save a log. The main points that came up were: > > > > * Executables built for the O32 FP64 ABI require this kernel config > > change and older kernel versions will refuse to load them. So the > > kernel needs to be upgraded before installing any binaries built > > for the new FP ABI. > > > > * Normally the support for an additional ABI would be included in > > release N.0 and used in N+1. Since this was not present in 10.0, it > > would be possible for users to start upgrading to bullseye while > > still running a kernel that does not support O32 FP64. We need to > > prevent them getting a broken system. > > > > * Julien proposed that libc6 would have a preinst check on the kernel > > when it is changed to use the new FP ABI. Presumably all binaries > > built for the new FP ABI should also have a versioned dependency on > > at least this version of libc6. > > > > So I don't see any reason not to update the kernel configuration > > already, as it will remain compatible with the O32 FPXX binaries in > > buster. Only the user-space changes in unstable (libc6 and toolchain) > > need to be carefully coordinated. > > > Here's the irc log for the record: > > < bwh> jcristau: While you are here, could you have a quick look at #949259? > < jcristau> that's kind of awkward > < jcristau> maybe it's ok because it's only mips, but... > < bwh> but what? > < jcristau> well i'd normally expect bullseye to run on buster r0 > < jcristau> what's the failure mode if the kernel doesn't support O32_FP64? > < bwh> syq_: Can you answer? > < bwh> jcristau: It looks to me like exec will fail for programs built for > the new FP ABI > < jcristau> so they'll need to get a dependency on a new libc with a preinst > check? > < bwh> jcristau: That seems like a reasonable approach > < bwh> that + prominent notice in the release notes > < syq_> jcristau: it will complain that not support such binary > < syq_> jcristau: if kernel doesn't enable FP64 > > I think you can go ahead provided that: > - enabling this support in the kernel doesn't break previously-supported > userspace
I think it's fine enabling support for it in the stable kernel. > - Aurélien as glibc maintainer is OK with this plan Well I am not sure it can be handled at the glibc level: - It's not clear to me how to detect the kernel support O32_FP64. We indeed have a check for the kernel version in the glibc preinst check in order to make sure all the syscalls used by the glibc are available. New syscalls are only added in major upstream kernel versions, so it's just fine to check for a minimum version. Now we are talking about a change that is introduced only in Debian kernels in a minor stable version. It's not clear to me which version to use in the preinst check given people can use backport kernels or use their own kernel. - Not all binaries depends on glibc. go binaries for example do not depends on glibc. It's not clear to me if they will also start using the new FP ABI. If so I guess we need to add the same check in all their preinst scripts. So overall it looks like something to me that should go in the release notes instead, just like we do for an ISA level raise. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
