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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Rick Macklem
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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Conrad Meyer-2
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 <[hidden email]> 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
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "[hidden email]"
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Alan Somers-2
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 <[hidden email]> 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 <[hidden email]> 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
> > _______________________________________________
> > [hidden email] mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> > To unsubscribe, send any mail to "[hidden email]"
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "[hidden email]"
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"