From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 1565A1F5AE for ; Sun, 2 Aug 2020 19:02:30 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4C9023857C73; Sun, 2 Aug 2020 19:02:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4C9023857C73 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1596394948; bh=0aI8htcFqLKs9RDQnY1EqiG1e5Ren+VVomPEExYPyz8=; h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=xW11ZkUSrdfgwwBmncMRDoaM2jZgpFwgFRgum5HZaPQllnmz9q7XDXkN6oGE8St6j 2p58ZtfI4pT6zpAwnN8CA4goMxSVXsuoo+sqzLxcnJ7KogAl5EaGAJDGhhJwymwwto I8FVFhM5CRUCnIRet+9A4SOxSDllU0YlCtDzgnMw= Received: from esa2.hgst.iphmx.com (esa2.hgst.iphmx.com [68.232.143.124]) by sourceware.org (Postfix) with ESMTPS id 1AA133857C66 for ; Sun, 2 Aug 2020 19:02:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1AA133857C66 IronPort-SDR: xqCPoUDj2jbviKR1q3gTyib8j4hgAcMQhujNL5unCDU/kJfsdITDPOn9mEMNpthNwa7PusvlCg 5wFv26U1Cn25RB+9AuG0oxZAudc/APZeOyDSWj9UXhOwk+OXHoby3JTORKkTIGtGE6exE4oaDp 8d/eKvs+xBiao8LWGNFmRPmVPYWEy13HLrjs4x9NOO+ez+Qp5ho31soOuS2enh452RiYBKawdY lyv9BbxzTYaVAqIs89/DwFOLeF21pn8q5u6TBViwOp+1uoBC6yGyquF3tLcPQBTq9ZiVK5X75I yUg= X-IronPort-AV: E=Sophos;i="5.75,427,1589212800"; d="scan'208";a="247056568" Received: from uls-op-cesaip02.wdc.com (HELO uls-op-cesaep02.wdc.com) ([199.255.45.15]) by ob1.hgst.iphmx.com with ESMTP; 03 Aug 2020 03:02:26 +0800 IronPort-SDR: /oxJLWKbWojwMKwfR55uA3zL7bghtpknbt/iNv06NQyeAwbSSv6bsBWIC78gf/lsQ6DYrfchOA pkVOgphD4ALA== Received: from uls-op-cesaip01.wdc.com ([10.248.3.36]) by uls-op-cesaep02.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Aug 2020 11:49:47 -0700 IronPort-SDR: rIqZS4XHSI2qI2OuXdGq3dXnV7hffLjGQl+GO/yyQuCTihrGgenkrhY9FbMwooHgJyfBzOPEtY 2zlj2tU7hiSA== WDCIronportException: Internal Received: from unknown (HELO redsun52) ([10.149.66.28]) by uls-op-cesaip01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Aug 2020 12:02:23 -0700 Date: Sun, 2 Aug 2020 20:02:19 +0100 (BST) To: Adhemerval Zanella Subject: Re: [PATCH 3/5] login: Add 64-bit time support In-Reply-To: <47eaf2e2-5912-bb69-6489-6215213add58@linaro.org> Message-ID: References: <20200729205117.2925113-1-adhemerval.zanella@linaro.org> <20200729205117.2925113-3-adhemerval.zanella@linaro.org> <47eaf2e2-5912-bb69-6489-6215213add58@linaro.org> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: "Maciej W. Rozycki via Libc-alpha" Reply-To: "Maciej W. Rozycki" Cc: libc-alpha@sourceware.org, Alistair Francis , Joseph Myers Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On Thu, 30 Jul 2020, Adhemerval Zanella via Libc-alpha wrote: > >> New symbols for getutent, getutent_r, getutid, getutid_r, getutline, > >> getutline_r, getutmp, getutmpx, getutxent, getutxid. getutxline, > >> pututline, pututxline, updwtmp, updwtmpx, and login are added to > >> all architecture but s390-32 (which already added 64-bit time support > >> on 32-bit ABI on glibc 2.9). > > > > I thought those structures appeared in external files (/var/run/utmp, > > /var/log/wtmp, /var/log/lastlog), which means changing them is problematic > > even with symbol versioning. Do the files keep their existing formats > > with the new versions of the functions translating to and from the 64-bit > > format when reading / writing those files? Do they get new formats with > > the old versions of the functions instead being the ones that translate > > (if so, what is the process distributions are expected to use to convert > > existing files on upgrade / enable old wtmp files in the old format to > > continue to be read by new code)? I think a detailed description of the > > overall strategy for maintaining compatibility with existing data in files > > is needed, both in the patch / patch series description and in the NEWS > > file describing anything required to be done on upgrade to avoid losing or > > corrupting data. > > > > The strategy I used was the same done by s390-32 some time ago, where > the var/run/utmp, /var/log/wtmp, /var/log/lastlog would use the new > 64-bit time regardless and the 32-bit compat symbols convert the 32-bit > entries to the internal 64-bit ones. Afaik there is not conversion tool > to handle that, so the system administration was supposed to reset such > files in a glibc upgrade. Hmm, there could be many copies of glibc used at once on a single system (e.g. for different ABIs) all accessing the same login records on behalf of different programs, and the intended process has been agreed upon it would seem so that administrators could make the switch as they would see fit rather than being forced to do so at the time of a glibc upgrade: . Maciej