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-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id CD1521F462 for ; Thu, 25 Jul 2019 15:49:18 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; q=dns; s=default; b=jrhPg vyGnUTKIVUanqHOOKxTOYXNAdfbqCddBndjHRilayJD4sm+oQ0Io2ytT5kVG3Nfz 1EzxBkB5FCM730Xbo3JpDWJj5ubkFmcc3E7MH432NpKzdwk9o+3tBRHUrAhn5Wum XS7lskVqDhQzQ9We0IN1RcPXEODLPWc6p+NKXc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; s=default; bh=o8y9Xz/d5IH Jq7tHlOH5HP+Xxis=; b=xrN7DUeF2PfQsm5a3v5HEWLMerHIFu1RCOhLoB1nMzU 0LNHYD98stB0FGX9CCLUA294au+gqkA23YeNefx7omEAMMIAMp5NNxTjMvzXXtn2 ReJSyc8jfbehjNYUVoa9X38yoj8hP6dk3vcH0/9K227dW/U+cmsJby9eCXwZS8hA = Received: (qmail 130211 invoked by alias); 25 Jul 2019 15:49:16 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 130198 invoked by uid 89); 25 Jul 2019 15:49:16 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: relay1.mentorg.com Date: Thu, 25 Jul 2019 15:49:09 +0000 From: Joseph Myers To: Florian Weimer CC: Andreas Schwab , Arnd Bergmann , Zack Weinberg , Alistair Francis , GNU C Library Subject: Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable In-Reply-To: <87bly4snx5.fsf@oldenburg2.str.redhat.com> Message-ID: References: <87ftnx6i0m.fsf@oldenburg2.str.redhat.com> <877e9950hj.fsf@oldenburg2.str.redhat.com> <87a7e522wb.fsf@oldenburg2.str.redhat.com> <87r27hzrjd.fsf@oldenburg2.str.redhat.com> <87ef3hzqjw.fsf@oldenburg2.str.redhat.com> <8736jwjqkq.fsf@oldenburg2.str.redhat.com> <878st8u3qp.fsf@oldenburg2.str.redhat.com> <87bly4snx5.fsf@oldenburg2.str.redhat.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1152306461-192448910-1564069749=:5744" ---1152306461-192448910-1564069749=:5744 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT On Mon, 8 Jul 2019, Florian Weimer wrote: > > I'm talking about legacy 32-bit architectures. > > Ah. Yes, I one would hope that. > > But there has been talk of a kernel option to remove it even there, and > a suggestion that glibc would try the 64-bit time_t system call first, > to see if it is available, and prefer that. > > I think this would be quite … wrong. glibc should generally use the 64-bit time_t system call first on legacy 32-bit architectures (and especially in cases such as futex where there is a large amount of logic in glibc at a higher level in the syscall, which it is particularly important to avoid duplicating for different time_t choices), not because of systems with the 32-bit syscall removed where it was previously part of the kernel ABI expected by glibc (those are not something reasonably supportable), but to avoid duplication and code bloat at both the source and binary level and to have a single consistent design (32-bit functions wrap the corresponding 64-bit ones, in all cases where the function is defined in C rather than through syscalls.list) rather than attempting to define what is or is not a sufficiently trivial function implementation that duplication is not a problem. -- Joseph S. Myers joseph@codesourcery.com ---1152306461-192448910-1564069749=:5744--