From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19441 invoked by alias); 3 Jun 2017 11:27:52 -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 19425 invoked by uid 89); 3 Jun 2017 11:27:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-10.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=mater X-HELO: mail-qk0-f194.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=tq3B4WkakUqRzqplOqYKWFDg6q9fEPKmpSPVaEwRU7Q=; b=ES1NEsSIoNW82GudNFsuBmxjgOKAgb0AAMhKUEW82eFszxiMdNEJLWiTvUmTWcw2Mb 4P5/M0jIjIDQpejy3YVCpaDWCFpxlwxD79K7eVFT2GREz0JbrSKtYVkGINfLYr8+/PqQ RpUPLhq+r341rH2ufNdBM0zFYmrETkfGeqTv1isCxDoWAIqOumlp+VrhuUk5Bw+IY5Zy xz1Foi9n2BkCWaEYoqBf3nTvbbm9w2bL3nxVjtw2upWSfFarrtXLqdh3GN8K29tY4dwE EJu4VFBbB2WqBgjDTO4LfBbhIcrc1kvauWoUCEzNwFpuVOiiLyWGSPyvly5TM2q7aMgC RFCQ== X-Gm-Message-State: AKS2vOylHb/idjAUiKeKbP+xLZb24qxVLw0FRx63eWvIc7B1dOZ19j8t MdYDKPz8wJ2fv+u2h6h7MYUIyo2Cow== X-Received: by 10.55.105.133 with SMTP id e127mr13716673qkc.19.1496489273435; Sat, 03 Jun 2017 04:27:53 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1493901791-13438-1-git-send-email-adhemerval.zanella@linaro.org> <1493901791-13438-2-git-send-email-adhemerval.zanella@linaro.org> <8ceeaabf-110f-31fe-516b-18f2fe6710f8@gotplt.org> <7412360d-c776-532b-e22c-dd3f0048cfba@linaro.org> <7f07b067-a074-d670-88b1-3da917451c71@redhat.com> <77f9ac84-620a-a408-c448-14a6978f5d2e@linaro.org> From: "H.J. Lu" Date: Sat, 03 Jun 2017 11:27:00 -0000 Message-ID: Subject: Re: [PATCH v3 2/2] posix: Implement preadv2 and pwritev2 To: Florian Weimer Cc: Andreas Schwab , Adhemerval Zanella , Zack Weinberg , Siddhesh Poyarekar , GNU C Library Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2017-06/txt/msg00150.txt.bz2 On Sat, Jun 3, 2017 at 4:23 AM, Florian Weimer wrote: > On 06/03/2017 01:04 PM, H.J. Lu wrote: >> On Sat, Jun 3, 2017 at 1:22 AM, Andreas Schwab wrote: >>> On Jun 02 2017, "H.J. Lu" wrote: >>> >>>> The x86-64 LO_HI_LONG can't be used for p{readv,writev}{64}v2. Add a >>>> new macro, LO_HI_LONG_FLAGS, to pass the off{64}_t and flags arguments. >>> >>> Why can't LO_HI_LONG just pass the padding unconditionally on x86_64? >>> >> >> To avoid the unnecessary (long) (((uint64_t) (val)) >> 32). > > I think the question is why you can't define it like this: > > (val), 0 > > ? Are you concerned about the additional overhead of passing that > unnecessary zero at the end of the parameter list for other system > calls? Or would this result in an observable kernel interface > difference and break stuff? My patch has ndex 7b8bd79..a3fe2fa 100644 --- a/sysdeps/unix/sysv/linux/x86_64/sysdep.h +++ b/sysdeps/unix/sysv/linux/x86_64/sysdep.h @@ -389,4 +389,9 @@ #undef LO_HI_LONG #define LO_HI_LONG(val) (val) +/* Provide a macro to pass the off{64}_t and flags arguments on + p{readv,writev}{64}v2. */ +#undef LO_HI_LONG_FLAGS +#define LO_HI_LONG_FLAGS(val, flags) (val), 0, (flags) + #endif /* linux/x86_64/sysdep.h */ For LO_HI_LONG, it doesn't mater what the second one is. It makes no difference if -1 is passed. Why bother with 0? -- H.J.