[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 29 Oct 2019 15:52:45 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] remaining steps for time64 switchover
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
