RFC: should copy_file_range(2) use size_t or off_t for length argument

Alan Somers asomers at freebsd.org
Sat Jul 27 23:34:52 UTC 2019


I agree.  Full compatibility is more important than a slight boost to
efficiency.
-Alan

On Sat, Jul 27, 2019 at 11:17 AM Conrad Meyer <cem at freebsd.org> wrote:
>
> Just my 2¢: keep the 1:1 Linux compatible interface.  Requiring
> programs to loop over N x 2^31 copies of larger files on 32-bit
> platforms does not impose significant extra syscall burden on copy
> programs over the wider off_t, and it fits the pattern of many
> existing synchronous IO APIs (size_t lengths).
>
> I think there is some benefit to matching other OS's non-POSIX
> function APIs exactly when we choose to use those same names and
> concepts — ifdef soup is painful.  And developers target Linux first.
>
> Cheers,
> Conrad
>
> On Sat, Jul 27, 2019 at 9:40 AM Rick Macklem <rmacklem at uoguelph.ca> wrote:
> >
> > Hi,
> >
> > r350315 implemented a Linux compatible copy_file_range(2) syscall.
> > Since Linux used a length argument of size_t and a return argument
> > type of ssize_t, I did the same.
> >
> > Kostik has suggested that making these off_t would allow a full 64bit
> > copy be done on 32bit arches.
> > Here is the snippet of discussion we have had:
> > Kostik Belousov wrote:
> > > >Kostik Belousov wrote:
> > >> >I sat to write the compat32 shims, and only then noted that len has size_t
> > >> >type.  Why is it size_t and not off_t ?
> > > I wrote:
> > >> Well, that's what Linux did.
> > >>
> > >> Also, since it returns ssize_t, it can't do more than SSIZE_MAX
> > >> (generally 1/2 of SIZE_T_MAX). Returning ssize_t is also what Linux
> > >> does and is consistent with read(2)/write(2).
> > >
> > >If changing the length argument type to off_t, it is reasonable to change
> > >the return type to off_t as well.  We already have the lseek(2) syscall that
> > >requires two return registers on 32bit.
> > >
> > >Note that it is reasonable for read(2) to take length as size_t-typed
> > >parameter, because size_t is the type for object sizes. There is no
> > >object in user address space for copy_file_range(2) API, so potentially
> > >wider off_t is acceptable and is in fact useful there. It is useful on
> > >32bit machines where FreeBSD size_t is 32bit, while off_t is 64bit.
> >
> > So, what do others think?
> > (My only concern w.r.t. changing the arguments to off_t is Linux compatibility.)
> >
> > rick
> > _______________________________________________
> > freebsd-fs at freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> > To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"


More information about the freebsd-fs mailing list