From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21451 invoked by alias); 3 Jun 2017 11:29:45 -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 21424 invoked by uid 89); 3 Jun 2017 11:29:42 -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= 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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=n0Oq1WfgPDqcNpRL/E3+92ud3b3wQqEwFXinya0kf5Q=; b=q9+7R/8MlnvXbPHKXhrBWLUIpe/SLboEpNQyhz2K+cSU8Q2Tj3IL2WFbU0iGDAOH0i AvuX0lK5+46bVOQA/l0o3PsJxiPh4ysknjj1rjOSt3MAWSMhNmaIDZXi3X3gpNw2YWZY 7dupKQUnwP+DA3uy2laA8y06DZCiCOOasDSqEHwkVeb+8xBzI1IrWfXwtZV+HnBHuBHb jmoTyzG0xInxcTXMCpN+WmmVwiyYA7OFnY901uzlD3QUplra8I07zhZO/BUO2RUIes+R UkWc5cwM5Iz20sNGzgbCdmCwkCRdtRUMLM0U3GO5g/qQrtWG6fK9jWS56fkVoBAA16Dh 1wNQ== X-Gm-Message-State: AODbwcD8qhelAV1f/MRrKC04Vkt6r2GO6omyCIsrCPvcnotYi3lm5KgA cJMTwx1wWw1jpxzXDAYIgP8d2I7gaw== X-Received: by 10.55.142.70 with SMTP id q67mr13729008qkd.247.1496489383832; Sat, 03 Jun 2017 04:29:43 -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:29: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/msg00151.txt.bz2 On Sat, Jun 3, 2017 at 4:27 AM, H.J. Lu wrote: > 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? > BTW, LO_HI_LONG_FLAGS is still needed for x32 even if LO_HI_LONG passes the second argument for x86-64. -- H.J.