From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14874 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 17:12:59 -0300 Message-ID: <87253cf1316d89402502069c2a4e7b6b@dragora.org> 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; 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="268797"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Roundcube Webmail/1.3.8 Cc: Laurent Bercot To: musl@lists.openwall.com Original-X-From: musl-return-14890-gllmg-musl=m.gmane.org@lists.openwall.com Sun Oct 27 21:13:20 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 1iOoub-0017la-JR for gllmg-musl@m.gmane.org; Sun, 27 Oct 2019 21:13:18 +0100 Original-Received: (qmail 10208 invoked by uid 550); 27 Oct 2019 20:13:14 -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 10189 invoked from network); 27 Oct 2019 20:13:13 -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:Cc:To:From:Date: Content-Transfer-Encoding:Content-Type:MIME-Version:Sender:Reply-To: 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=q0aNWWuvA8Ls53kw4Y0/n/NBgrk/GzBvNC1C1Lnkrqo=; b=V1b6+kPMnw8rsKr2xBLvf0RnkD 7xSOCTRw4bZLxpOoleuo81wFc8nUJSTVsRPtlKt+4O+D4nhQJqSz6/CksktcOK6PQbPOUU2wBEtyE g7L/Nu331zTHjw3kKWcV8XIYmdeIJcmmpJbNPCyDPvUgXKg7JbIUKXmg8kpTKY1w0HMBNZp6aSeNA SAGic25LpzqcdGLKgmhTNK0zMX2nLW1KL7WEEd7pLUUy7nDhXa5OjP40o2YmYZUHvm0gVTDuX0L53 f1b2ZLP8lqGNE+hk3A4wJQotO8Fdd/hVT40IDhPpZZSz84CAgTcaWEXNemB1u2jC7qR8TE5wf+w30 7mIfAUtQ==; In-Reply-To: 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:14874 Archived-At: Hello Laurent, Can utmps work without s6?. I mean, independently of the init system or=20 distribution... El 2019-10-27 05:32, Laurent Bercot escribi=C3=B3: >> Or here. So, the story on utmpx: we can either >>=20 >> 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 >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >=20 > 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? >=20 > 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. >=20 > I'm not aware of any distribution that uses musl, doesn't use utmps, > and still keeps on-disk utmpx records. >=20 > -- > Laurent