From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14583 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] Add copy_file_range system call Date: Mon, 19 Aug 2019 22:11:25 -0400 Message-ID: <20190820021125.GE9017@brightrain.aerifal.cx> References: <20190819234114.19848-1-arni@dagur.eu> <20190820005635.GC9017@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="7730"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) Cc: =?utf-8?B?w4Fybmk=?= Dagur To: musl@lists.openwall.com Original-X-From: musl-return-14599-gllmg-musl=m.gmane.org@lists.openwall.com Tue Aug 20 04:11:44 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hztcc-0001wI-4m for gllmg-musl@m.gmane.org; Tue, 20 Aug 2019 04:11:42 +0200 Original-Received: (qmail 10235 invoked by uid 550); 20 Aug 2019 02:11:39 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 10209 invoked from network); 20 Aug 2019 02:11:38 -0000 Content-Disposition: inline In-Reply-To: <20190820005635.GC9017@brightrain.aerifal.cx> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14583 Archived-At: On Mon, Aug 19, 2019 at 08:56:35PM -0400, Rich Felker wrote: > On Mon, Aug 19, 2019 at 11:41:14PM +0000, Árni Dagur wrote: > > This patch was based on commit 53147f9, which added splice and vmsplice. > > --- > > The function signature in the glibc manpage specifies `loff_t` instead > > of `off_t`, for both `copy_file_range` and `splice`. In musl, however, > > the function signature for `splice` specifies `off_t`, so I did the > > same here. I'm not an experienced C programmer, so that may have been > > wrong. > > I think this looks ok. Regarding loff_t vs off_t, loff_t is the > kernel's API type for functions that take a 64-bit offset > unconditionally rather than glibc providing 32-bit off_t and 64-bit > off_t versions of them. This is gratuitous for musl where off_t is > always 64-bit. We provide loff_t as a macro that expands to off_t, but > even if it were a typedef the types woule be the same type, so it's > fine to use off_t here, and I think it's the cleanest and most > consistent with what we're doing elsewhere even if it's not textually > the same as the man page. > > > include/unistd.h | 1 + > > src/linux/copy_file_range.c | 8 ++++++++ > > 2 files changed, 9 insertions(+) > > create mode 100644 src/linux/copy_file_range.c > > > > diff --git a/include/unistd.h b/include/unistd.h > > index 9485da7a..00cc7042 100644 > > --- a/include/unistd.h > > +++ b/include/unistd.h > > @@ -188,6 +188,7 @@ char *get_current_dir_name(void); > > int syncfs(int); > > int euidaccess(const char *, int); > > int eaccess(const char *, int); > > +ssize_t copy_file_range(int fd_in, off_t *off_in, int fd_out, off_t *off_out, size_t len, unsigned flags); > > #endif > > Is there a reason for the choice to put it in unistd.h? Similar > functions seem to have gone in fcntl.h. unistd.h does not make the > loff_t type available which could be problematic to callers using it, > since they really should (for API compatibility) be declaring the > objects whose addresses they pass as loff_t. > > If glibc does it here and exposes loff_t in unistd.h we might need to > consider doing that too with _GNU_SOURCE. OK I went and looked at what glibc did (glibc commit bad7a0c81f501fbbcc79af9eaa4b8254441c4a1f) and they define the function with arguments having type __off64_t and declare it in unistd.h. So I think the expectation is that you use off_t with it (or off64_t if doing the LFS dance on glibc with _FILE_OFFSET_BITS==32), loff_t is not needed as part of the API to invoke it, and your patch looks fine. Rich