From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14876 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Matias Fonzo Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] remaining steps for time64 switchover Date: Sun, 27 Oct 2019 18:53:14 -0300 Message-ID: References: <20191021024643.GA6192@brightrain.aerifal.cx> <20191027042645.GX16318@brightrain.aerifal.cx> <87253cf1316d89402502069c2a4e7b6b@dragora.org> <20191027211422.GA16318@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="158833"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Roundcube Webmail/1.3.8 To: musl@lists.openwall.com Original-X-From: musl-return-14892-gllmg-musl=m.gmane.org@lists.openwall.com Sun Oct 27 22:53:31 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 1iOqTa-000fBw-DT for gllmg-musl@m.gmane.org; Sun, 27 Oct 2019 22:53:31 +0100 Original-Received: (qmail 1293 invoked by uid 550); 27 Oct 2019 21:53:27 -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 1268 invoked from network); 27 Oct 2019 21:53:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dragora.org ; s=default; h=Message-ID:References:In-Reply-To:Subject:To:From:Date: Content-Transfer-Encoding:Content-Type:MIME-Version:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=cqQX8VFas3rjwt3kEiTYOJGRYZod98D6kV9WCdhsaP8=; b=jX2c76dbJNLOfcC2TQ2GsJcTII IOxJT6XHfoJ4dYP9SoGUIf0X9xmY84++oLIo8/IgKs1dqPkpbk11X34es0pftbeOMNvOU3dDC0cdT nDZvzNtV6O6fb3axBpFHIdfT5nj4WQFUXUB23VC1/qd8lmQxL4nTLnY9+P12NzNT/faLvvFDsnpG4 qzycqMt6X7KVRPVY8PN7mgN1fVBa86rFJbhsMntb8oYtRv2sOPZdrDR4OOonU8GGjd2Cxe2y6skYy TjY+7Iay9+fujjBESua4brNeyaFEqlWVCOOacxyI5oQkDCOPptlWR7K73+jhqdfSx7zELPTQcapaX +eC8t0aw==; In-Reply-To: <20191027211422.GA16318@brightrain.aerifal.cx> X-Sender: selk@dragora.org X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel112.wnpower.com X-AntiAbuse: Original Domain - lists.openwall.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dragora.org X-Get-Message-Sender-Via: cpanel112.wnpower.com: authenticated_id: selk@dragora.org X-Authenticated-Sender: cpanel112.wnpower.com: selk@dragora.org Xref: news.gmane.org gmane.linux.lib.musl.general:14876 Archived-At: Hello Rich, El 2019-10-27 18:14, Rich Felker escribi=C3=B3: > On Sun, Oct 27, 2019 at 05:12:59PM -0300, Matias Fonzo wrote: >> Hello Laurent, >>=20 >> Can utmps work without s6?. I mean, independently of the init >> system or distribution... >=20 > 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. >=20 I thought so, but there could be a configuration-side requirement or=20 daemon (setup) to work properly, I don't know. We are using perp for=20 Dragora. >=20 >=20 >> El 2019-10-27 05:32, Laurent Bercot escribi=C3=B3: >> >>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=C3=A9lie), the utmp/wtmp records, by design, do not survive a reboo= t, >> >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