[PATCH v2] linux: Use 'long int' for timespec tv_nsec on x32 (BZ #16437)

[Rich Felker]

On Sat, Dec 11, 2021 at 12:26:21PM +0100, Arnd Bergmann wrote:
> On Sat, Dec 11, 2021 at 1:47 AM Paul Eggert <eggert@cs.ucla.edu> wrote:
> > On 12/10/21 16:08, Rich Felker wrote:
> > > this is a bug fix for a serious conformance problem
> > > that's going to have people writing wacky code to work around x32
> >
> > In my experience it's not a significant conformance issue. I've had very
> > little trouble writing user code that's portable to x32 struct timespec.
> > Generally speaking the code just works anyway; in the few cases where
> > there might have been trouble the fixes were trivial and non-wacky.
> >
> > Anybody writing portable struct timespec code has more important
> > problems than this (e.g., Solaris 11 'stat' can set st_mtim.tv_nsec to a
> > negative integer, something that's caused me far more hassle). And
> > anybody porting to x32 has waaaaayy more important problems than this.
> >
> > > if anyone even actually cares about x32
> >
> > If the x32 user community (small as it is) doesn't care about this issue
> > then we all have better things to do than worry about it.
> 
> Would it help to resume the thread about removing the kernel support,
> followed by removing glibc support? The last time Andy brought this up
> was three years ago[1], and it was borderline then with about five users
> saying they actually used it at the time and several kernel developers
> speaking out in favor of removing the kernel bits.
> 
> The timing probably isn't bad either, with Debian 11 and Ubuntu 22.04
> (both of which include marginal support for x32) being supported for
> years to come. Anyone building their own stuff can rely on linux-5.15lts
> and an existing glibc release to do the same.
> 
>          Arnd
> 
> [1]  https://lore.kernel.org/lkml/CALCETrXoRAibsbWa9nfbDrt0iEuebMnCMhSFg-d9W-J2g8mDjw@mail.gmail.com/

I know this would make things easier for kernel folks, but I'd really
like to avoid removal and especially avoid being part of the impetus
for removal. I suspect a large portion of real-world x32 users are
musl users, and musl's x32 port has never had the problem this thread
is about.

If there is renewed desire for removal, could we look at doing it in a
way that enables moving support to userspace? That might actually
already be possible with the framework that was added for intercepting
syscalls (for wine) and binfmt_misc.

Rich