The time64 switchover has happened!

The time64 switchover has happened!

[Rich Felker]

I just pushed the patch series switching 32-bit archs to 64-bit time.
Between now and next release, 32-bit archs' ABIs are intended-stable
but tentative, and could change before release, but I don't intend to
do that unless some serious unforseen problem is discovered during
testing and is impractical to fix without changing something.

The actual switchover commit is
38143339646a4ccce8afe298c34467767c899f51 and the series ends with
d6dcfe4d0c58856690ecbad4cf191d7c9ee1a4a8.

Now, it's time for testing. I've done some build and smoke tests of
OpenSSL, Python, Perl, strace, coreutils, busybox (git master needed
to fix time64 problems), and a few other packages, but large
distro-scale package builds will be the real test of how easy this
transition is going to be.

For distributions that aren't a "make world" sort of thing (mix of
package versions), I know there will be issues with mixing old and new
libraries and applications; I'm not sure yet how severe they'll be.
This would be very useful to have reports/feedback on. Such distros
should make preparations, and short of detailed research to determine
how much or little breakage there will be, should make users aware
that a global dist-upgrade operation (with all libs and apps rebuilt
for time64) is the safest and recommended way to move to the first
release that will incorporate time64 musl.

Re: The time64 switchover has happened!

[A. Wilcox]

[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]

On Nov 3, 2019, at 1:25 AM, Rich Felker <dalias@libc.org> wrote:
> 
> I just pushed the patch series switching 32-bit archs to 64-bit time.
> Between now and next release, 32-bit archs' ABIs are intended-stable
> but tentative, and could change before release, but I don't intend to
> do that unless some serious unforseen problem is discovered during
> testing and is impractical to fix without changing something.
> 
> The actual switchover commit is
> 38143339646a4ccce8afe298c34467767c899f51 and the series ends with
> d6dcfe4d0c58856690ecbad4cf191d7c9ee1a4a8.
> 
> Now, it's time for testing. I've done some build and smoke tests of
> OpenSSL, Python, Perl, strace, coreutils, busybox (git master needed
> to fix time64 problems), and a few other packages, but large
> distro-scale package builds will be the real test of how easy this
> transition is going to be.
> 
> For distributions that aren't a "make world" sort of thing (mix of
> package versions), I know there will be issues with mixing old and new
> libraries and applications; I'm not sure yet how severe they'll be.
> This would be very useful to have reports/feedback on. Such distros
> should make preparations, and short of detailed research to determine
> how much or little breakage there will be, should make users aware
> that a global dist-upgrade operation (with all libs and apps rebuilt
> for time64) is the safest and recommended way to move to the first
> release that will incorporate time64 musl.

For the purposes of our try build test packaging, is it safe to call this commit "1.2.0 alpha1"?

Best,
--arw 

--
A. Wilcox (Sent from my iPhone - not signed)
Project Lead, Adélie Linux
https://www.adelielinux.org/


[-- Attachment #2: Type: text/html, Size: 2993 bytes --]

Re: The time64 switchover has happened!

[Rich Felker]

On Sun, Nov 03, 2019 at 10:22:48AM -0600, A. Wilcox wrote:
> On Nov 3, 2019, at 1:25 AM, Rich Felker <dalias@libc.org> wrote:
> > 
> > I just pushed the patch series switching 32-bit archs to 64-bit time.
> > Between now and next release, 32-bit archs' ABIs are intended-stable
> > but tentative, and could change before release, but I don't intend to
> > do that unless some serious unforseen problem is discovered during
> > testing and is impractical to fix without changing something.
> > 
> > The actual switchover commit is
> > 38143339646a4ccce8afe298c34467767c899f51 and the series ends with
> > d6dcfe4d0c58856690ecbad4cf191d7c9ee1a4a8.
> > 
> > Now, it's time for testing. I've done some build and smoke tests of
> > OpenSSL, Python, Perl, strace, coreutils, busybox (git master needed
> > to fix time64 problems), and a few other packages, but large
> > distro-scale package builds will be the real test of how easy this
> > transition is going to be.
> > 
> > For distributions that aren't a "make world" sort of thing (mix of
> > package versions), I know there will be issues with mixing old and new
> > libraries and applications; I'm not sure yet how severe they'll be.
> > This would be very useful to have reports/feedback on. Such distros
> > should make preparations, and short of detailed research to determine
> > how much or little breakage there will be, should make users aware
> > that a global dist-upgrade operation (with all libs and apps rebuilt
> > for time64) is the safest and recommended way to move to the first
> > release that will incorporate time64 musl.
> 
> For the purposes of our try build test packaging, is it safe to call
> this commit "1.2.0 alpha1"?

I don't see any reason not to, but I'm not familiar with the details
of how your package versioning works. There won't be a branch of
time64 released as 1.1.x; if there are any future 1.1.x releases
they'll be bugfix backports for EOL'd time32.

Rich

Re: The time64 switchover has happened!

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

On Sun, Nov 03, 2019 at 01:25:07AM -0500, Rich Felker wrote:
[...]
> Now, it's time for testing. I've done some build and smoke tests of
> OpenSSL, Python, Perl, strace, coreutils, busybox (git master needed

FWIW, there are quite a few places in strace test suite that rely
on specific system calls being invoked by some libc functions.
I suppose some of these tests are broken by this change.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: The time64 switchover has happened!

[Rich Felker]

On Sun, Nov 03, 2019 at 07:33:38PM +0300, Dmitry V. Levin wrote:
> On Sun, Nov 03, 2019 at 01:25:07AM -0500, Rich Felker wrote:
> [...]
> > Now, it's time for testing. I've done some build and smoke tests of
> > OpenSSL, Python, Perl, strace, coreutils, busybox (git master needed
> 
> FWIW, there are quite a few places in strace test suite that rely
> on specific system calls being invoked by some libc functions.
> I suppose some of these tests are broken by this change.

I haven't tried yet, but I think there's a good chance they're not
broken. For operations that only pass a time to the kernel, rather
than receiving one back, musl only makes the time64 syscall if the
argument does not fit in 32 bits. For the other direction, there's no
way to know in advance whether the result will fit so the time64 one
has to be tried first, but for the most part that's just stat-family
and clock_gettime (which ideally happens via vdso instead anyway).

As noted before, strace does break at build time due to use of the
sys/{ipc,sem,shm,msg}.h headers to get the IPC structs and command
macros. If they don't exist configure has a fallback to use the kernel
headers, which is the right thing to do, so you have to hack/force
these configure results to build. Hopefully upstream will just remove
use of the libc headers for this since it's conceptually wrong anyway.

Rich