From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14870 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Laurent Bercot" Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] remaining steps for time64 switchover Date: Sun, 27 Oct 2019 08:32:57 +0000 Message-ID: References: <20191021024643.GA6192@brightrain.aerifal.cx> <20191027042645.GX16318@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="166288"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: eM_Client/7.2.36908.0 To: musl@lists.openwall.com Original-X-From: musl-return-14886-gllmg-musl=m.gmane.org@lists.openwall.com Sun Oct 27 09:33:14 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1iOdz5-000h4o-Ej for gllmg-musl@m.gmane.org; Sun, 27 Oct 2019 09:33:11 +0100 Original-Received: (qmail 11586 invoked by uid 550); 27 Oct 2019 08:33:09 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 11568 invoked from network); 27 Oct 2019 08:33:09 -0000 In-Reply-To: <20191027042645.GX16318@brightrain.aerifal.cx> X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedufedrleeigddufedtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecupfgfoffgtffkveetuefngfdpqfgfvfenuceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkjghfrhgfgggtgfesthhqredttderjeenucfhrhhomhepfdfnrghurhgvnhhtuceuvghrtghothdfuceoshhkrgdqughivghtlhhisggtsehskhgrrhhnvghtrdhorhhgqeenucfrrghrrghmpehmohguvgepshhmthhpohhuthenucevlhhushhtvghrufhiiigvpedt Xref: news.gmane.org gmane.linux.lib.musl.general:14870 Archived-At: >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=20 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=C3=A9lie), 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