From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14886 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] remaining steps for time64 switchover Date: Tue, 29 Oct 2019 15:52:45 -0400 Message-ID: <20191029195245.GG16318@brightrain.aerifal.cx> References: <20191021024643.GA6192@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="82819"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14902-gllmg-musl=m.gmane.org@lists.openwall.com Tue Oct 29 20:53:02 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1iPXY3-000LNm-SR for gllmg-musl@m.gmane.org; Tue, 29 Oct 2019 20:52:59 +0100 Original-Received: (qmail 3821 invoked by uid 550); 29 Oct 2019 19:52:57 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 3803 invoked from network); 29 Oct 2019 19:52:57 -0000 Content-Disposition: inline In-Reply-To: <20191021024643.GA6192@brightrain.aerifal.cx> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14886 Archived-At: On Sun, Oct 20, 2019 at 10:46:43PM -0400, Rich Felker wrote: > The attached patch series on top of present git master (commit > 9b2921bea1d5017832e1b45d1fd64220047a9802) should contain all changes > needed for fully working time64 on 32-bit archs, in a form that's > plausibly ready for commit (no makeshift hacks just to get things > demonstrably working). The one omission I'm aware of is what to do > with struct utmpx, which is not actually used at present in any libc > interfaces and thus not part of the ABI surface of libc. That will be > addressed in a separate thread. > > Comments and basic testing are welcome at this point. It should be > possible to build for any of the 32-bit archs, but I have only tested > build for a few and only tested execution on i386 and sh. > > Some useful checks for anyone wanting to help test, especially on the > more obscure archs: > > [...] > > - Anything look odd about time-related types? timeval/timespec members > at positions that aren't naturally aligned? I tested this on i386 (with low alignment requirement, only 4 bytes) with the attached program and it seems like I indeed got the padding slots as-intended on the ipc types. This should mean the adjacent explicit-padding members have no effect on other archs using the same changes but with natural alignment, which matches the intent. As usual mips and ppc are gratuitously different and seemed right to me but should perhaps be double-checked at some point. However since they have natural alignment the worst that could happen is leaving extra padding slots we don't need. > [...] > > - Does it work with clock set post-2038? I tested this for arch/sh on j2 (fpga) which was the most convenient place I had a 5.x kernel, and indeed it works! > Being that only the final switchover patches are a big step to take, > I'll probably start pushing the earlier patches in this series pretty > soon, but want to give a little time for more eyes on them. I'm going to push them all as a group very soon. > Note that the final switchovers are split out by arch right now, > mainly because that was the way that made sense to create them (sed to > replace arch name, apply to next arch, fix rejects manually) but also > because it helps compare/review them against each other. It would be > possible to squash them together for final merge but I probably won't. I've actually opted to squash them together just because it facilitates writing a meaningful commit message that explains the ABI properties, consequences, stability policy, mechanics of the change, etc. in a non-redundant manner (the explanation is the same across all archs). The diff naturally splits by arch just by the default pathname sorting (or by applying the diff just to the appropriate dir under arch/), so nothing is lost in terms of ability to look at changes for individual archs separately or compare them. Rich