Date: Sat, 27 Jul 2019 16:39:53 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: "freebsd-fs@freebsd.org" <freebsd-fs@FreeBSD.org> Cc: "kib@freebsd.org" <kib@FreeBSD.org> Subject: RFC: should copy_file_range(2) use size_t or off_t for length argument Message-ID: <YTBPR01MB33122A0A1B3CD9D8EC18A0ECDDC30@YTBPR01MB3312.CANPRD01.PROD.OUTLOOK.COM>
next in thread | raw e-mail | index | archive | help
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 siz= e_t >> >type. Why is it size_t and not off_t ? > I wrote: >> Well, that's what Linux did. >>=20 >> 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 th= at >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 compatibil= ity.) rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTBPR01MB33122A0A1B3CD9D8EC18A0ECDDC30>