[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 20 Dec 2018 11:33:59 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Data structures defined by both linux and musl
* Rich Felker <dalias@...c.org> [2018-12-19 19:30:44 -0500]:
> On Tue, Dec 18, 2018 at 08:41:53PM +0100, Arnd Bergmann wrote:
> > I recently discussed with Rich about the work needed to get 64-bit time_t
> > support into musl. One of the first steps he identified was to find out which
> > interfaces we would want to abstract or wrap for a new ABI given that we
> > have to make a binary incompatible interface anyway.
> >
> > I have found all the data structures that are provided by both the kernel
> > headers and the musl headers now, and annotated what I think we the
> > path forward could be. I already provided the same list on IRC, but
> > here is a (slightly updated) copy for everyone else.
>
> Thank you. For those just joining now, the context of this is that
> support for 64-bit time_t on 32-bit archs probably requires, and at
> least is best done with, a new ABI, so far known as the ".2" ABI
> (because the ldso would end in ".2" instead of ".1"). This would be an
> opportunity to fix lots of ABI mistakes where extensibility of even
> support for current functionality is lacking. If done, this would not
> be a fork of musl and would not be dropping existing ABIs. Rather,
> internal refactoring would eliminate the assumption that the
> ABI-with-application types match the ABI-with-kernel/syscall types,
> performing translation back and forth where needed. On the existing
> ".1" ABIs, this translation would mostly be the identity
> transformation, but on archs where we're already doing some hacks to
> fix up kernel ABI bugs (sysvipc on big endian, mips stat structure,
> x32 stuff, etc.) the hacks could be replaced by used of this
> translation infrastructure.
lesson of ilp32 was that libc cannot generally translate between
a user and kernel abi (otherwise it could be done in userspace).
the problematic cases are when user talks to the kernel directly
using libc types in a way that the libc cannot do the translation.
interfaces where the libc does not know the type, just an opaque
pointer: ioctl, fcntl, getsockopt, setsockopt, raw syscall
interfaces where translation would require malloc, but should be
as-safe and not fail with ENOMEM: sendmmsg, readv, writev,...
direct communication channel to the kernel that may expose the
abi incompatibility: netlink, sysfs, procfs
types related to signal handling that may require sighandler
wrapping to translate: siginfo_t, ucontext_t
time_t may not be affected by these, but it shows that translation
is fragile in general, i wonder if we can ensure correct behaviour
in all cases. there is also the problem of linux headers which may
use and redefine libc types and user code may need to use those.
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.
