mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Late time64 changes on the way
Date: Sat, 21 Dec 2019 15:01:19 -0500	[thread overview]
Message-ID: <20191221200119.GU1666@brightrain.aerifal.cx> (raw)
In-Reply-To: <20191219183951.GA1236@brightrain.aerifal.cx>

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


      reply	other threads:[~2019-12-21 20:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-19 18:39 Rich Felker
2019-12-21 20:01 ` Rich Felker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191221200119.GU1666@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).