[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 28 Oct 2019 18:22:16 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] remaining steps for time64 switchover
On Sun, Oct 27, 2019 at 12:26:45AM -0400, Rich Felker wrote:
> On Sun, Oct 20, 2019 at 10:46:43PM -0400, Rich Felker wrote:
> > demonstrably working). The one omission I'm aware of is what to do
> > with struct utmpx, which is not actually used at present in any libc
> > interfaces and thus not part of the ABI surface of libc. That will be
> > addressed in a separate thread.
>
> Or here. So, the story on utmpx: we can either
>
> 1. match the current size on 32-bit archs, but move the timeval to
> unused space at the end where a time64 version fits, or
>
> 2. match the current size and layout of the 64-bit struct, making it
> possible to share records between 32- and 64-bit processes on the
> same machine.
>
> Keep in mind that this struct is not used anywhere in libc presently,
> but normally it's used as a format for on-disk records.
>
> I'm kinda leaning towards option 2, but being that I don't use (and
> hate) utmp, I'd rather hear opinions from people who do use it. Either
> way time fields in existing data will break, so it's a question of
> whether that one-time breakage is already sufficient to go a bit
> further and get 32/64 compat afterwards.
Thanks to git://repo.or.cz/musl-tools.git abi checker, I found a few
other minor details that have been overlooked. In addition to utmp[x],
there's also struct lastlog which depends on time_t. For it there's
really no choice to be made; change necessarily breaks size/layout of
the type, and the change that falls out naturally from time_t changing
is the "right" one (matches 64-bit struct too).
There's also ntptimeval, which I'd mentioned at one point before but
forgotten about. It's not used anywhere in libc and dubious that we
even have the type defined at all. So changes in it are no big deal.
Finally, prstatus_t (struct elf_prstatus) has timeval members, and as
I understand it this structure is ABI for core files or something. I
can't find any code that's actually using it though. This structure
can't maintain both ABI and API, so presumably API must break, i.e.
the types of the members must change. Or we just remove it entirely.
I'd be rather happy if we could do that, actually. Can any distro
folks chime in on whether you've actually encountered users of this
cruft?
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.
