Date: Sun, 27 Oct 2019 08:32:57 +0000 From: "Laurent Bercot" <ska-dietlibc@...rnet.org> To: musl@...ts.openwall.com Subject: Re: [PATCH] remaining steps for time64 switchover >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. I don't use the libc's utmpx, but I maintain utmps, which is a secure implementation of utmp, including the definition of struct utmpx. I haven't been following the time64 thing closely. The current struct utmpx definition includes a struct timeval. Will it need to change, or will musl's struct timeval change be enough and naturally propagate so the struct utmpx will become time64-compatible? On-disk data is not a problem. On the distro that I know uses utmps (Adélie), the utmp/wtmp records, by design, do not survive a reboot, so a reboot will fix everything - and will be mandatory anyway on arches where the musl ABI changes. I'm not aware of any distribution that uses musl, doesn't use utmps, and still keeps on-disk utmpx records. -- Laurent
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.