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.