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

[Conrad Meyer]

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"