From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41698 invoked by alias); 10 Feb 2020 22:27:50 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 41683 invoked by uid 89); 10 Feb 2020 22:27:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=H*i:sk:3cfa9b1, H*f:sk:3cfa9b1 X-HELO: mail-lj1-f193.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JZgu76ScXvXaWkDyl4jJTikCqM8VZ+5mdzgF7mMxN18=; b=G4MoLLhMQg2QeEwG+ANgVbiw++nXzl+Q8Hr+/iXQN01ek+d2M5slVFETgokNBHyTEl O3OswY7wuVG15S7IFMhg8K+HKi674g6+xc+qgk4uFVijE3WLGyXWiCO60w/Ff4elfdou E6FnLuZCL/zz3wkySqDTnoLAxXt2scrMD/3Nj93iQVRh9N9kVW8/svIIj2V8hATOobAH T8sFmkOBZEdRCKfiarD3pR0kceHbFoH17tXg3agIO1pLwXuIPOhZ/Z3MF0RYmvtezn9N 8jThU8BPn6eydW/sYH+Zb3A1xXR6D9cPcRTLl47T9pTfdZvYbxtLP7reaRA3HkORuMGY HpWg== MIME-Version: 1.0 References: <20200210174325.6566-1-alistair.francis@wdc.com> <20200210174325.6566-2-alistair.francis@wdc.com> <3cfa9b1a-935d-a3fc-08cc-5e929a8f49e8@linaro.org> In-Reply-To: <3cfa9b1a-935d-a3fc-08cc-5e929a8f49e8@linaro.org> From: Alistair Francis Date: Mon, 10 Feb 2020 22:27:00 -0000 Message-ID: Subject: Re: [PATCH v2 1/6] sysv/linux: Rename alpha functions to be alpha specific To: Adhemerval Zanella Cc: GNU C Library Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2020-02/txt/msg00328.txt.bz2 On Mon, Feb 10, 2020 at 1:53 PM Adhemerval Zanella wrote: > > > > On 10/02/2020 18:35, Zack Weinberg wrote: > > On Mon, Feb 10, 2020 at 4:25 PM Alistair Francis wrote: > >> On Mon, Feb 10, 2020 at 1:11 PM Zack Weinberg wrote: > >>> > >>> On Mon, Feb 10, 2020 at 12:50 PM Alistair Francis > >>> wrote: > >>>> > >>>> These functions are alpha specifc, rename them to be clear. > >>> > >>> These functions were meant to be generic. I put the file in > >>> s/u/s/l/alpha because it was only *used* on Alpha, at the time. > >>> > >>> What's stopping you from using these functions on all architectures? > >> > >> The Alpha functions use 32-bit versions of the timeval struct for a > >> 64-bit architecture. For all other architectures we want to use the > >> word size version (regardless of time_t size) for the timeval struct. > >> That's the main difference. > > > > I'm sorry, I haven't been following the discussion all that closely. > > Why is it necessary to use a 32-bit timeval struct (with 32-bit > > time_t, I presume) *only* on Alpha? Is there no way we can smooth > > over this difference so that, as you say, > > Alpha is an outlier here, it is the only 64-bit architecture that did > the 32 bit to 64 bit transition some time ago. All the generic code > assumes that 64-bit architectures always have 64-bit time_t > (__ASSUME_TIME64_SYSCALLS). > > And the old interface is not exported and *only* meant to be used in > compat symbols, different than the current way of handling y2038 > prof code (where the user might still define the ABI with _TIME_SIZE). > > That's why I think alpha compat code should be compartmentalized on > alpha sysdep folder. Agreed. That is the goal with this patch. This patch moves and renames the Alpha functions to make sure there is no conflict with any of the new work. Alistair > > > > >> If Alpha didn't have this requirement we could then just remove the > >> Alpha specific overrides after this series and use all of the new > >> generic y2038 infrastructure. > > > > Also, even if we really are stuck with an Alpha-specific struct > > timeval32, I don't see why that affects the definitions of the > > conversion functions? > > > > zw > >