Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp538714ybt; Sat, 13 Jun 2020 12:28:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxQwFLZIv8AfKxoBs7hTB+NqATyL8bQLCDOnPNI17si0COlZTCYpHAm9eu4LVX0oLPLapkq X-Received: by 2002:a17:906:17c1:: with SMTP id u1mr19785430eje.47.1592076539170; Sat, 13 Jun 2020 12:28:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592076539; cv=none; d=google.com; s=arc-20160816; b=PVjlPTr/YQTtdkWKx8ZopUnPucwJEDooWPoGIDioZi6qYEhJoHinsiYWNOuTxm479m 2rJ+i/YbdMSRV4zMJA56QnNdQ2Fg3n93+evO2CC+Gwvz/H2GO5xMP5u/QaZg2KDrURzc Aq5fx6M/A4poohG5G9Za0dpBRAhXN7wOl3+jkN99cjJB6KaoEOzcj6JHH3j+kqSFPE1z xkMLsUijyO05EIwbvB94cj5yqH1G3RbuytLiynMi9ezC0fmAZAaZTZHaAxOp5g+MMoYU E3HioNIeJKvV9tY8Lrmn+17kQtF0dk1QXkGHdl5ZH4dAikeBzW96QQJxflc97QP+Ww54 74pg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=M+YUWNBWEfikN/AQNOpzEL4HzEKeNUxwOav6AnWUfsM=; b=dcgOmOfwJUXdY91VCFIRGQpwJkwDAiY3zpCWft82Jjfisc4U0nvfVrFKRqgq3t6dbx qyO0pFGXIUhaqbvxK3AOy6+RG/Z0Vme63XUxg80jpR4p6VB3t96zCubTxzYy5cz8rWn6 vYASrUgXEch4yhEjo5h1Gr61XdrvTkI1X+5rwDTpeIQi/KZ9Dd+Lg0pGLmA8euaMRqdr xAiwLGCDe5HUlRgLopN+0C3xVrjKPkSiS8296oI5d2nxkFnMAPuZzRk3JAX9y6Om7xXT G9xt+9YoiCoxC1GUKBKNN6pYhJbViOh75jVzm5I9mySJmWauCVqmP1910MugnytTkZXa +2Aw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k23si7311263ejk.35.2020.06.13.12.28.36; Sat, 13 Jun 2020 12:28:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726624AbgFMT0D (ORCPT + 99 others); Sat, 13 Jun 2020 15:26:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38550 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726304AbgFMTZ7 (ORCPT ); Sat, 13 Jun 2020 15:25:59 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 69F3BC03E96F; Sat, 13 Jun 2020 12:25:58 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: tonyk) with ESMTPSA id A2F4D2A10FC Subject: Re: [RFC 0/4] futex2: Add new futex interface To: "H.J. Lu" Cc: LKML , Thomas Gleixner , Peter Zijlstra , Florian Weimer , malteskarupke@web.de, GNU C Library , Linux API , Ingo Molnar , dvhart@infradead.org, kernel@collabora.com, krisman@collabora.com, pgriffais@valvesoftware.com References: <20200612185122.327860-1-andrealmeid@collabora.com> From: =?UTF-8?Q?Andr=c3=a9_Almeida?= Message-ID: Date: Sat, 13 Jun 2020 16:25:46 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello H.J., On 6/12/20 4:35 PM, H.J. Lu wrote: > On Fri, Jun 12, 2020 at 11:53 AM André Almeida via Libc-alpha > wrote: >> - Is expected to have a x32 ABI implementation as well? In the case of >> wait and wake, we could use the same as x86_64 ABI. However, for the >> waitv (aka wait on multiple futexes) we would need a proper x32 entry >> since we are dealing with 32bit pointers. > > x32 should be able to use the same i386 compat systcall entry. Will it be > problem? > Indeed, you are right. In the last iteration of this work, I had some problems dealing with x32 ABI, but this new interface doesn't have the same problem anymore. We can use the same sys_waitv_time64 interface for both i368 and x32. >> > > H.J. > Thanks, André