[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 21 Dec 2019 15:01:19 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Late time64 changes on the way
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
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.
