From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-80047-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 8070 invoked by alias); 3 Jun 2017 14:16:40 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 8057 invoked by uid 89); 3 Jun 2017 14:16:39 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=
X-HELO: mail-qt0-f196.google.com
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:in-reply-to:references:from:date
         :message-id:subject:to:cc;
        bh=VkIZb5qTVIt3SqppmnNVkk8n1SgTG6OZTUD2y/dQfzE=;
        b=Xectq9wVBsNU/zS4DFfye2PrUe2a7LaKudJ6rOegPbv1DKja15GQQlapPlDRS63l1n
         NSkHf4AXUO0WTpzKQTbLXDws5OGy2KY4Dh4hakkUhQdI2p5DwuJuHKgjqEGYdQNLMkcb
         P88EggatdineaGuXAhoPO9t6QkTKse+CSGz0QYk9hYuuV2hH+Jf10yJhgirKMvLi5csc
         /m0XCJorfc68o/4GlC0u2FXLOexLhdkeRqjiAJRK2QxJ+DOEeMnHskHzYUB6M9192fsZ
         +BJNi9ZeB+0Eb38650l3+4IoeFx5fqXtlnJ8MyzJJ/u7KHZapSXYX9dFxkLCVGyK9eJz
         8tBA==
X-Gm-Message-State: AODbwcBlmbKcB1rB/fpRfZuhNX41xrRXiVKjZgFk39gUbg780I5/U9yJ
	G3+LwVehP1DgJMapmz6aDTODMzPIRA==
X-Received: by 10.237.61.145 with SMTP id i17mr13312623qtf.241.1496499401012;
 Sat, 03 Jun 2017 07:16:41 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <14aca656-8e0f-01b2-ead6-94a9f200f33e@panix.com>
References: <1493901791-13438-1-git-send-email-adhemerval.zanella@linaro.org>
 <7412360d-c776-532b-e22c-dd3f0048cfba@linaro.org> <CAMe9rOpu=yRUr=bHE=h2CJA7e0=U8qz5g5M_PL3GKAtLoUmmJA@mail.gmail.com>
 <CAKCAbMi95KU=kO1vyj7O4GpHFngOpjDGxCog83nnaYjrRwOF4Q@mail.gmail.com>
 <7f07b067-a074-d670-88b1-3da917451c71@redhat.com> <b2e4c8cc-0fe7-aa9b-08c8-389e7bb0fa76@linaro.org>
 <CAKCAbMgAuA0-Zc1n_BwjGW767semHr-ApjUWecCo4h9gJk=unQ@mail.gmail.com>
 <f9508771-891d-090e-49e8-b4e85a0f6f77@linaro.org> <bca5b48f-9a51-f980-eaee-853602dfca34@redhat.com>
 <77f9ac84-620a-a408-c448-14a6978f5d2e@linaro.org> <CAMe9rOoRXFH0qeuwpCvLtHJDGn0r6B+KqRbpfK-Um8VAoXF+4g@mail.gmail.com>
 <m2poelh45i.fsf@linux-m68k.org> <CAMe9rOrRuOKfXFoTm2MKpufn2NUZ39Nxo9RSY7U0Ss0LW=TZ2w@mail.gmail.com>
 <e6d26a42-f5d2-bada-d44a-42e58b4d1543@redhat.com> <CAMe9rOqPfbjYPgEqmkWEAht+ZzGZk4wikhVCejUuMWtTdQjr8w@mail.gmail.com>
 <f52bb683-6de8-f0e8-cb89-3a74b77600ca@panix.com> <CAMe9rOorX7JWSd87oRxf3hkwdAu3p9PRBxP_NkzogbO71h7mNg@mail.gmail.com>
 <14aca656-8e0f-01b2-ead6-94a9f200f33e@panix.com>
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Sat, 03 Jun 2017 14:16:00 -0000
Message-ID: <CAMe9rOokZsM4iWXFHf1uwCcRsMe87fDmJc44QJkJbrXpMMNuwA@mail.gmail.com>
Subject: Re: [PATCH v3 2/2] posix: Implement preadv2 and pwritev2
To: Zack Weinberg <zackw@panix.com>
Cc: Florian Weimer <fweimer@redhat.com>, Andreas Schwab <schwab@linux-m68k.org>, 
	Adhemerval Zanella <adhemerval.zanella@linaro.org>, Siddhesh Poyarekar <siddhesh@gotplt.org>, 
	GNU C Library <libc-alpha@sourceware.org>
Content-Type: text/plain; charset="UTF-8"
X-SW-Source: 2017-06/txt/msg00159.txt.bz2

On Sat, Jun 3, 2017 at 6:58 AM, Zack Weinberg <zackw@panix.com> wrote:
> On 06/03/2017 09:52 AM, H.J. Lu wrote:
>> On Sat, Jun 3, 2017 at 6:48 AM, Zack Weinberg <zackw@panix.com> wrote:
>>> If nothing else, always passing the unused argument as 0 will reduce
>>> confusion when people inspect these syscalls, e.g. through the debugger
>>> interface or the seccomp filter interface.  I think that's a sufficient
>>> reason to do it.  These are all I/O syscalls that can block, it's the
>>> wrong place to be shaving cycles.
>>
>> LO_HI_LONG_FLAGS is still needed for x32, regardless what we
>> do with LO_HI_LONG.
>
> But x32 won't get the definition of LO_HI_LONG that expands to "(val),
> 0)" - that would be wrong - so why won't LO_HI_LONG(val), flags work?
>

X32 inherits LO_HI_LONG from x86-64.  If we change x86-64
LO_HI_LONG, x32 needs to redefine LO_HI_LONG.


-- 
H.J.