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.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,NICE_REPLY_A, 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 62FE71F5AE for ; Sun, 2 Aug 2020 22:05:23 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C838B385702F; Sun, 2 Aug 2020 22:05:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C838B385702F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1596405921; bh=H7OheW/S3xYxUYoHzAaiw+gLlA0fgeqqKjI/xRSppsU=; h=To:References:Subject:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=EZnCdZ5WyEIq3IshyIowR73b7ZHLmkbb+JP4hZO2XWWxTqLedDTftE50tnTqtE8ps gVf/NehE5keVlmDK4Jqg6CcAxyMZ4sBSKjeBOipjyTf2cPxj4qhcmFRhR/76d9zkKe EjMl2Kwt+IqXvV6PmDIXSZ/bMMmxq75WSF20oqb0= Received: from mail-qv1-xf44.google.com (mail-qv1-xf44.google.com [IPv6:2607:f8b0:4864:20::f44]) by sourceware.org (Postfix) with ESMTPS id 78B33385DC1A for ; Sun, 2 Aug 2020 22:05:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 78B33385DC1A Received: by mail-qv1-xf44.google.com with SMTP id w2so4450520qvh.12 for ; Sun, 02 Aug 2020 15:05:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:autocrypt:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=H7OheW/S3xYxUYoHzAaiw+gLlA0fgeqqKjI/xRSppsU=; b=c0aAnVmyZFzx1zZatZMNNXlImvvQL392r1oiwP+NHo5hdawZmJGiz1aXnWkRZjBbt5 hgP+QvCDk76KgrX36WfSHdf/8QEY6znEvYmXeldyHNufAZxC4YYV1OHdVFKEPJc5KP2K n5Dv5S6196+XC0jagPlpjiFKgEtxpbRrVj8UaDB//vvZEtKSsTAeW8RCsouWzbZZVhrZ 6gXSZ2818/h5UaPAHBgyp3Q9S3TZQ6d+ObjuHRyLmtsjO3c4FIxVrYO9fIHj7z9wQIlI 0R05WGt2bG57G7EEhRlVcw/hr15oWS4AMxumO8SaIWqbLq+rSlSWv7c9+4KPdqtre1y6 cRbg== X-Gm-Message-State: AOAM531vUPLAsE2SZEYkl57gohC2j/j2DrRHXg6pDp7vH2BhbQ4Vp8cP 1MjXmi81saFQT05r2agS3KT8EGQyycc= X-Google-Smtp-Source: ABdhPJzUBLf0S2AkR1Lv2Xj2V9EIOv8soloIf1gvX8eN63ChuxhTDpT7C5vKx6GwGv0n0BrCcQ4sgA== X-Received: by 2002:a0c:ff02:: with SMTP id w2mr13996576qvt.206.1596405917742; Sun, 02 Aug 2020 15:05:17 -0700 (PDT) Received: from [192.168.1.4] ([177.194.48.209]) by smtp.googlemail.com with ESMTPSA id i19sm17403924qkk.68.2020.08.02.15.05.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 02 Aug 2020 15:05:17 -0700 (PDT) To: "Maciej W. Rozycki" References: <20200729205117.2925113-1-adhemerval.zanella@linaro.org> <20200729205117.2925113-3-adhemerval.zanella@linaro.org> <47eaf2e2-5912-bb69-6489-6215213add58@linaro.org> Autocrypt: addr=adhemerval.zanella@linaro.org; prefer-encrypt=mutual; keydata= mQINBFcVGkoBEADiQU2x/cBBmAVf5C2d1xgz6zCnlCefbqaflUBw4hB/bEME40QsrVzWZ5Nq 8kxkEczZzAOKkkvv4pRVLlLn/zDtFXhlcvQRJ3yFMGqzBjofucOrmdYkOGo0uCaoJKPT186L NWp53SACXguFJpnw4ODI64ziInzXQs/rUJqrFoVIlrPDmNv/LUv1OVPKz20ETjgfpg8MNwG6 iMizMefCl+RbtXbIEZ3TE/IaDT/jcOirjv96lBKrc/pAL0h/O71Kwbbp43fimW80GhjiaN2y WGByepnkAVP7FyNarhdDpJhoDmUk9yfwNuIuESaCQtfd3vgKKuo6grcKZ8bHy7IXX1XJj2X/ BgRVhVgMHAnDPFIkXtP+SiarkUaLjGzCz7XkUn4XAGDskBNfbizFqYUQCaL2FdbW3DeZqNIa nSzKAZK7Dm9+0VVSRZXP89w71Y7JUV56xL/PlOE+YKKFdEw+gQjQi0e+DZILAtFjJLoCrkEX w4LluMhYX/X8XP6/C3xW0yOZhvHYyn72sV4yJ1uyc/qz3OY32CRy+bwPzAMAkhdwcORA3JPb kPTlimhQqVgvca8m+MQ/JFZ6D+K7QPyvEv7bQ7M+IzFmTkOCwCJ3xqOD6GjX3aphk8Sr0dq3 4Awlf5xFDAG8dn8Uuutb7naGBd/fEv6t8dfkNyzj6yvc4jpVxwARAQABtElBZGhlbWVydmFs IFphbmVsbGEgTmV0dG8gKExpbmFybyBWUE4gS2V5KSA8YWRoZW1lcnZhbC56YW5lbGxhQGxp bmFyby5vcmc+iQI3BBMBCAAhBQJXFRpKAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJ EKqx7BSnlIjv0e8P/1YOYoNkvJ+AJcNUaM5a2SA9oAKjSJ/M/EN4Id5Ow41ZJS4lUA0apSXW NjQg3VeVc2RiHab2LIB4MxdJhaWTuzfLkYnBeoy4u6njYcaoSwf3g9dSsvsl3mhtuzm6aXFH /Qsauav77enJh99tI4T+58rp0EuLhDsQbnBic/ukYNv7sQV8dy9KxA54yLnYUFqH6pfH8Lly sTVAMyi5Fg5O5/hVV+Z0Kpr+ZocC1YFJkTsNLAW5EIYSP9ftniqaVsim7MNmodv/zqK0IyDB GLLH1kjhvb5+6ySGlWbMTomt/or/uvMgulz0bRS+LUyOmlfXDdT+t38VPKBBVwFMarNuREU2 69M3a3jdTfScboDd2ck1u7l+QbaGoHZQ8ZNUrzgObltjohiIsazqkgYDQzXIMrD9H19E+8fw kCNUlXxjEgH/Kg8DlpoYJXSJCX0fjMWfXywL6ZXc2xyG/hbl5hvsLNmqDpLpc1CfKcA0BkK+ k8R57fr91mTCppSwwKJYO9T+8J+o4ho/CJnK/jBy1pWKMYJPvvrpdBCWq3MfzVpXYdahRKHI ypk8m4QlRlbOXWJ3TDd/SKNfSSrWgwRSg7XCjSlR7PNzNFXTULLB34sZhjrN6Q8NQZsZnMNs TX8nlGOVrKolnQPjKCLwCyu8PhllU8OwbSMKskcD1PSkG6h3r0AquQINBFcVGkoBEACgAdbR Ck+fsfOVwT8zowMiL3l9a2DP3Eeak23ifdZG+8Avb/SImpv0UMSbRfnw/N81IWwlbjkjbGTu oT37iZHLRwYUFmA8fZX0wNDNKQUUTjN6XalJmvhdz9l71H3WnE0wneEM5ahu5V1L1utUWTyh VUwzX1lwJeV3vyrNgI1kYOaeuNVvq7npNR6t6XxEpqPsNc6O77I12XELic2+36YibyqlTJIQ V1SZEbIy26AbC2zH9WqaKyGyQnr/IPbTJ2Lv0dM3RaXoVf+CeK7gB2B+w1hZummD21c1Laua +VIMPCUQ+EM8W9EtX+0iJXxI+wsztLT6vltQcm+5Q7tY+HFUucizJkAOAz98YFucwKefbkTp eKvCfCwiM1bGatZEFFKIlvJ2QNMQNiUrqJBlW9nZp/k7pbG3oStOjvawD9ZbP9e0fnlWJIsj 6c7pX354Yi7kxIk/6gREidHLLqEb/otuwt1aoMPg97iUgDV5mlNef77lWE8vxmlY0FBWIXuZ yv0XYxf1WF6dRizwFFbxvUZzIJp3spAao7jLsQj1DbD2s5+S1BW09A0mI/1DjB6EhNN+4bDB SJCOv/ReK3tFJXuj/HbyDrOdoMt8aIFbe7YFLEExHpSk+HgN05Lg5TyTro8oW7TSMTk+8a5M kzaH4UGXTTBDP/g5cfL3RFPl79ubXwARAQABiQIfBBgBCAAJBQJXFRpKAhsMAAoJEKqx7BSn lIjvI/8P/jg0jl4Tbvg3B5kT6PxJOXHYu9OoyaHLcay6Cd+ZrOd1VQQCbOcgLFbf4Yr+rE9l mYsY67AUgq2QKmVVbn9pjvGsEaz8UmfDnz5epUhDxC6yRRvY4hreMXZhPZ1pbMa6A0a/WOSt AgFj5V6Z4dXGTM/lNManr0HjXxbUYv2WfbNt3/07Db9T+GZkpUotC6iknsTA4rJi6u2ls0W9 1UIvW4o01vb4nZRCj4rni0g6eWoQCGoVDk/xFfy7ZliR5B+3Z3EWRJcQskip/QAHjbLa3pml xAZ484fVxgeESOoaeC9TiBIp0NfH8akWOI0HpBCiBD5xaCTvR7ujUWMvhsX2n881r/hNlR9g fcE6q00qHSPAEgGr1bnFv74/1vbKtjeXLCcRKk3Ulw0bY1OoDxWQr86T2fZGJ/HIZuVVBf3+ gaYJF92GXFynHnea14nFFuFgOni0Mi1zDxYH/8yGGBXvo14KWd8JOW0NJPaCDFJkdS5hu0VY 7vJwKcyHJGxsCLU+Et0mryX8qZwqibJIzu7kUJQdQDljbRPDFd/xmGUFCQiQAncSilYOcxNU EMVCXPAQTteqkvA+gNqSaK1NM9tY0eQ4iJpo+aoX8HAcn4sZzt2pfUB9vQMTBJ2d4+m/qO6+ cFTAceXmIoFsN8+gFN3i8Is3u12u8xGudcBPvpoy4OoG Subject: Re: [PATCH 3/5] login: Add 64-bit time support Message-ID: <848de37a-0825-4db1-f86e-88dae1ebf94a@linaro.org> Date: Sun, 2 Aug 2020 19:05:14 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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: Adhemerval Zanella via Libc-alpha Reply-To: Adhemerval Zanella Cc: libc-alpha@sourceware.org, Alistair Francis , Joseph Myers Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On 02/08/2020 16:02, Maciej W. Rozycki wrote: > 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: > . I think the strategy of using new filenames for UTMP_FILE as proposed by Joseph tends to be a slight better one than keeping multiple databases and add the extra complexity of syncing entries in multiples files. On the patches I am working, the default new utmp/utmpx symbols only reads/writes 64-bit time entries. The compat symbols, in the other hand, have a more complex logic: if the utmp/utmpx file is the default one (UTMP_FILE exported by newer glibc) the entries are read as 64-bit and converted to 32-bits; otherwise the register are read as 32-bit time_t (although it seems unlikely that application using compat symbols would set the database for the new UTMP_FILE). The new symbols do not have a logic on how to read old 32-bit database formats. It should be doable by either setting the file format base on utmp file name (through utmpname) or maybe by a GNU extension where the database type is advertise explicit. The usefulness of the ABI would be mainly to create some utmp/wtmp conversion tool, so I am not sure if it is really worth to implement it. But the main focus here is to *not* maintain multiple utmp databases, but rather to move new application to use y2038 ones due the inherent issue of 32-bit time database (which affects 64-bit architecture as well, modulo s390). The old utmp database should be use only by on compat applications that does not have 64-bit time support and this is another reason I think the 'utmp.trans' strategy is not the best one.