From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-80044-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 26166 invoked by alias); 3 Jun 2017 13:58:14 -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 26146 invoked by uid 89); 3 Jun 2017 13:58:13 -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-qk0-f193.google.com
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:cc:from:message-id:date
         :user-agent:mime-version:in-reply-to:content-transfer-encoding;
        bh=yBMKJSxwRQoIpUCch6mJx+ZTgg+bS6RfeX4ponatke8=;
        b=Zom7zINxeRuBp6jGNXxuc/47AHqmAPmdz5NdYny4HsZBxSxa8tuquzsEGIIciHJhK+
         7L9nD5r6E37vAU+Ytn9vXTg+1BQTXG0WJpd3uW6BvdQshqvvkA6liFSvH+AYjzjYgjB8
         jYNOTc97JCdUb9cO32Sx3MJC8KASg8IZbOcm/39totuBwHcZe2fl/NfVANwa9JQ6zJ3a
         Ujc9aSLc6O3kmkp/lkDevKgN/SLrU58IRF4oQbtf3uxSQfliSo8Se/X/hMJ4gI8KwJu2
         AZQqDNGRFNLHtvt6McMZY/wUBi6qLJn/IsomG6EitzgiznfmC6Skci9TldeYB0hqnQ5k
         BNgg==
X-Gm-Message-State: AKS2vOw8/Yn7oa5Gx/Pnd+zPpZoIDe49bchhFTnLzLQ8BwbtBfjddlGQ
	8luqxQ9Q7ZV8kfW9r6w=
X-Received: by 10.233.222.5 with SMTP id s5mr6791369qkf.190.1496498294994;
        Sat, 03 Jun 2017 06:58:14 -0700 (PDT)
Subject: Re: [PATCH v3 2/2] posix: Implement preadv2 and pwritev2
To: "H.J. Lu" <hjl.tools@gmail.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>
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>
From: Zack Weinberg <zackw@panix.com>
Message-ID: <14aca656-8e0f-01b2-ead6-94a9f200f33e@panix.com>
Date: Sat, 03 Jun 2017 13:58:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAMe9rOorX7JWSd87oRxf3hkwdAu3p9PRBxP_NkzogbO71h7mNg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-SW-Source: 2017-06/txt/msg00156.txt.bz2

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?

zw