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.