From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [216.12.86.13]) by sourceware.org (Postfix) with ESMTPS id EED9B3858D39 for ; Sat, 11 Dec 2021 14:49:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EED9B3858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=libc.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=libc.org Date: Sat, 11 Dec 2021 09:49:15 -0500 From: Rich Felker To: Arnd Bergmann Cc: Paul Eggert , GNU C Library development , Andy Lutomirski Subject: Re: [PATCH v2] linux: Use 'long int' for timespec tv_nsec on x32 (BZ #16437) Message-ID: <20211211144906.GC7074@brightrain.aerifal.cx> References: <20211210110233.1401640-1-adhemerval.zanella@linaro.org> <87mtl879ch.fsf@oldenburg.str.redhat.com> <20211211000844.GB7074@brightrain.aerifal.cx> <49f9e2d0-3252-78a6-0395-8901d82772fe@cs.ucla.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2021 14:49:20 -0000 On Sat, Dec 11, 2021 at 12:26:21PM +0100, Arnd Bergmann wrote: > On Sat, Dec 11, 2021 at 1:47 AM Paul Eggert 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