From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14875 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] remaining steps for time64 switchover Date: Sun, 27 Oct 2019 17:14:22 -0400 Message-ID: <20191027211422.GA16318@brightrain.aerifal.cx> References: <20191021024643.GA6192@brightrain.aerifal.cx> <20191027042645.GX16318@brightrain.aerifal.cx> <87253cf1316d89402502069c2a4e7b6b@dragora.org> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="254898"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14891-gllmg-musl=m.gmane.org@lists.openwall.com Sun Oct 27 22:14:38 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 1iOpry-0014Cm-6b for gllmg-musl@m.gmane.org; Sun, 27 Oct 2019 22:14:38 +0100 Original-Received: (qmail 9672 invoked by uid 550); 27 Oct 2019 21:14:35 -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 9653 invoked from network); 27 Oct 2019 21:14:35 -0000 Content-Disposition: inline In-Reply-To: <87253cf1316d89402502069c2a4e7b6b@dragora.org> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14875 Archived-At: On Sun, Oct 27, 2019 at 05:12:59PM -0300, Matias Fonzo wrote: > Hello Laurent, > > Can utmps work without s6?. I mean, independently of the init > system or distribution... Laurent could answer in better detail, but as a quick answer, there's no requirement from having s6 installed that you use it as your init system. Rich > El 2019-10-27 05:32, Laurent Bercot escribió: > >>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