From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) by sourceware.org (Postfix) with ESMTPS id 82EB6385E036 for ; Fri, 4 Jun 2021 16:49:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 82EB6385E036 Received: by mail-qk1-x732.google.com with SMTP id u30so9946957qke.7 for ; Fri, 04 Jun 2021 09:49:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2CtTNArkgUiX9jsuoE1kDjrI6ka9Nb9VznHXn3QrQrI=; b=YJKy2lmbvHRKXHeyjUn9BxkY3w7U5vhHeDIEyRKayhfxJXboAVeNlFf1NU2f4nCLqJ hcQ+EzX/rfOND87230sGTflfT+HnCmeaQrndfSqXuXs7PbzgErGLcIkSeCUqeLkGP6Zv tnz9TBJmdi6VMaFnvapVIexBxo37o8PQ8WNxeEnbiWwlYzLHpfwltmiVUGNtP5iKzQgw l/oBRJUkaXEdzjhOlbhbiyh+3OY/TCs9ct1FZGIe6zJW8N86UcaS/0msm7JM9WmSqoAB c4pZdcruPYv9WfFNNGbEYY3r8SK0kgWwjsmT1HkFGQGUBM/BoqcQB1yKEGZCwf8wypdG FgcA== X-Gm-Message-State: AOAM533Mxgy82diVqWZRbMZjOu42heUNT+pWb0+RfcR+oi3/cjyUEw6z kGwQkcRx19a/TpxxXzLMDFLrFQ== X-Google-Smtp-Source: ABdhPJxU81iWTXmzsWoVdUMa1XA7Hg52ePFDqCDNLB3RriV1u8udVzVeVo4EajpJN812WHkcNVO8ig== X-Received: by 2002:a05:620a:205e:: with SMTP id d30mr5012613qka.35.1622825396083; Fri, 04 Jun 2021 09:49:56 -0700 (PDT) Received: from [192.168.1.4] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id p12sm2063206qtw.61.2021.06.04.09.49.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Jun 2021 09:49:55 -0700 (PDT) Subject: Re: Patch review status for 64-bit time_t patches. To: Carlos O'Donell , Lukasz Majewski , libc-alpha , Florian Weimer References: <4cdce8bc-c8c3-d289-ffd8-7ca8692badd9@redhat.com> <479d261d-2c4a-a9e2-068b-9efa0985a8d9@redhat.com> <25af64e5-bb8d-96cd-558f-59d463877dcc@redhat.com> From: Adhemerval Zanella Message-ID: Date: Fri, 4 Jun 2021 13:49:52 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <25af64e5-bb8d-96cd-558f-59d463877dcc@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Fri, 04 Jun 2021 16:50:06 -0000 On 03/06/2021 00:56, Carlos O'Donell wrote: > On 5/31/21 5:09 PM, Carlos O'Donell wrote: >> On 5/27/21 5:46 PM, Carlos O'Donell wrote: >>> Adhemerval, Lukasz, >>> >>> I'm at ~6/25 patches reviewed. I started not by reviewing but by building additional >>> glibc packages for Fedora Rawhide and then testing in Rawhide. >>> >>> Testing looks good in Fedora Rawhide on top of Florian's recent merge in of the >>> most recent development changes. >>> >>> I'll continue reviewing these as discussed in order to ensure we can merge them >>> in a timely fashion. >> >> Just a quick status update. >> >> I'm at ~18/25 patches reviewed. >> >> I had a somewhat long discussion with Adhemerval on IRC about the new dual-time >> ABI and the dropping of the __glibc_reserved* entries form the public ABI. This >> is OK for the new ABI, but we must be careful we don't ever define __USE_TIME_BITS64 >> for any existing 64-bit time_t ABIs since it would be an ABI regression. >> >> I'm out of time today, but I'll come back tomorrow to try finish the reviews. > > I'm at ~21/25 patches reviewed. > > I went back over the sysvipc ABI again looking to see if I could make it match > up by putting back the reserved structure members to match the kernel ABI and > I could. > > I'm going to recommend we change to match the kernel ABI from a legacy perspective. Hi Carlos, I tried to follow your suggestion here and although feasible, it would required to provide a special struct_msqid64_ds_helper.h (and other similar sysvipc headers) for some specific architectures: arm, mips (all abis), and s390. This is due the special alignment requirement of changing the fields with __time_t to __time64. For instance, with even the extra two reserved fields for 'msqid_ds', the size increases from 88 to 96 on arm. And these extra arch-specific definitions is one thing I would like to avoid. As I commented with you on IRC, the sysvipc is really an legacy API and I don't expect the kernel to provide new control mechanism (that would require us to extend the control structures.