[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 11 Jul 2019 21:45:27 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Removing glibc from the musl .2 ABI
On Thu, Jul 11, 2019 at 06:58:38PM -0500, A. Wilcox wrote:
> (Full disclosure: I am the principal author of gcompat.)
>
> Hi,
>
> Now that gcompat has matured, I was wondering if perhaps musl should
> consider dropping the glibc ABI guarantees when the "2 ABI" lands.
It's not decided that it will, or at least not in the near term. I
think the other approach proposed to 64-bit time_t is a lot more
appealing to most existing 32-bit users. I've had out-of-band feedback
from one big user that they depend on ABI stability for the existing
32-bit arch+ABIs and hope there won't be a hard Y2038 EOL for them,
and I myself would also rather prefer not to have to do an ABI switch.
>From the beginning, ABI stability was one of the big promises of musl.
I realize we have "enough" time between now and 2038 for putting off
an ABI switch (except for ppl making embedded stuff with really long
lifetimes), so that users who care about ABI stability could stick
with .1 "for now", but then we just push the problem back and they're
unhappy in some moderately-distant future, and probably end up in a
mess when they realize they need time_t's representing times a decade
or two out sooner than they thought...
> This would make the LFS64 symbol mess completely moot.
Yes. Actually I'd like to move all of the ABI-compat symbols out of
ld-reachable symbol table and make them ABI-compat only. But I'd also
like to *improve* ABI-compat, e.g. making regexec from glibc libs safe
on 64-bit (where their regoff_t was wrong),
> It would also allow musl to "fix" a lot of dumb glibc decisions. I'm
> thinking specifically here of things like ctermid(3), which musl could
> actually implement correctly if it wasn't being held back by glibc
> defining L_ctermid as 9.
ctermid is something of a junk function anyway, but there are similar
non-junk interfaces affected. Identifying and overhauling them all is
probably a bigger project than I want to take on now, but I still
think it's a promising direction at some point in the future. Ideally
this might go hand in hand with making musl less Linux-centric, in the
form of developing a types ABI that's uniform across archs and meant
to be used natively on bare metal or non-Linux kernels.
> I'm aware this is probably controversial, and it will probably be shot
> down quickly, but I thought I would at least suggest this as an option.
>
> Thank you for your consideration.
Thanks for the feedback.
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.
