Late time64 changes on the way

Late time64 changes on the way

[Rich Felker]

Based on recent findings, I'm working on some late (in the sense of
late in the release cycle) time64 changes I didn't expect to be
making. In particular it was found that, without significant
time64-aware hacks on the application/other-libraries side, the
following would stop working when built for time64:

- socket timestamping (SO_TIMESTAMP[NS])
- sound (ALSA)
- video capture (V4L2)
- ppp (timeouts)
- legacy parallel ports (¯\_(ツ)_/¯)

The first 3, and possibly the first 4, are a pretty big deal -- "Sound
isn't going to work anymore unless you upgrade your kernel" is a big
blocker to adoption and would almost certainly leave us with a
situation where distros/users are trying to stick back with pre-time64
versions or use tricks to keep building new binaries as time32.

I already have a fix for the first queued (fallback to old options
that produce 32-bit timestamps with translation of the cmsg payload in
recvmsg) and an in-progress fix for the rest.

For sound, there are still pending patches to the kernel headers that
will be needed for it to work right:

https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=y2038-endgame

The needed ones will be backported/merged in musl-cross-make soon.

Once I push these changes, I'd love some assistance testing that they
actually work from users who have appropriate setups (32-bit userspace
with pre-time64 kernel, sound or video capture hardware, software for
using it). Please reply (or mention it on #musl) if you can help.

Rich

Re: Late time64 changes on the way

[Rich Felker]

On Thu, Dec 19, 2019 at 01:39:51PM -0500, Rich Felker wrote:
> Based on recent findings, I'm working on some late (in the sense of
> late in the release cycle) time64 changes I didn't expect to be
> making. In particular it was found that, without significant
> time64-aware hacks on the application/other-libraries side, the
> following would stop working when built for time64:
> 
> - socket timestamping (SO_TIMESTAMP[NS])
> - sound (ALSA)
> - video capture (V4L2)
> - ppp (timeouts)
> - legacy parallel ports (¯\_(ツ)_/¯)
> 
> The first 3, and possibly the first 4, are a pretty big deal -- "Sound
> isn't going to work anymore unless you upgrade your kernel" is a big
> blocker to adoption and would almost certainly leave us with a
> situation where distros/users are trying to stick back with pre-time64
> versions or use tricks to keep building new binaries as time32.
> 
> I already have a fix for the first queued (fallback to old options
> that produce 32-bit timestamps with translation of the cmsg payload in
> recvmsg) and an in-progress fix for the rest.

This work has all been pushed now, and seems to be working, at least
the sound part. I've successfully run aplay built against it and
observed it making failed time64 ioctls and falling back to the old
ones, and confirmed via gdb that the data in the resulting structs is
right, at least as best I can within the constraints of the modes
being used.

> For sound, there are still pending patches to the kernel headers that
> will be needed for it to work right:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=y2038-endgame
> 
> The needed ones will be backported/merged in musl-cross-make soon.

The uapi header parts are fairly simple and shouldn't have significant
conflicts with other changes to kernel (so they should work on a
fairly broad range of versions). I'd like it if these could be
factored out of the functional changes to kernel internals when being
committed upstream, but I suspect that's not possible without
introducing intermediate states where the kernel would be built with
broken ABI, unless a lot of further gratuitous work were done.

Anyway, this should be the diff that's needed:

https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/diff/include/uapi?id=0fb598f2876e7d9f6f184021ad77cf9935cbe481&id2=2d5d83981d9ac5c256a30818c9d8cb1443cbb0ce

and it's simple enough to do as its own thing and include in mcm,
distro patches. But I don't think the kernel can be compiled with
these changes applied, so it may be problematic for distros that
want to build their kernel and kernel-headers packages together. It
*might* work if the #ifndef __KERNEL__ additions are removed and a few
other small tweaks are made. I'd want to hear Arnd's comments on this
before suggesting folks do it though.

In any case it's perfectly fine to apply this just for the installed
kernel-headers, as long as you build the kernel without it applied.

Rich