Date: Sat, 26 Sep 2020 23:33:45 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: FreeBSD Hackers <freebsd-hackers@freebsd.org>, "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: RFC: should copy_file_range(2) remain Linux compatible or support special files? Message-ID: <YTBPR01MB3966966F82008C9E471708FCDD370@YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM>
next in thread | raw e-mail | index | archive | help
I know cross-posting is frowned upon, but I wanted everyone who might=0A= like to comment to see this.=0A= =0A= Currently copy_file_range(2) only supports regular files, which is compatib= le=0A= with the Linux one, where EINVAL is returned when either file descriptor=0A= refers to a non-regular file.=0A= =0A= Alan Somers would like to extend the syscall to handle special files.=0A= I think he has a couple of reasons for this (he can correct me):=0A= - When integrating it into "cp", he needed to provide a fallback for=0A= special files and similar fallbacks would probably be needed for=0A= other utilities like "dd".=0A= - iSCSI provides a "copy" operation which could be implemented using=0A= copy_file_range(2)/VOP_COPY_FILE_RANGE() if it supported special files.= =0A= =0A= kib@ was concerned that a copy from /dev/zero would fill a disk, but=0A= I think that issue can be dealt with by limiting the duration of the syscal= l=0A= to 1sec (so that the utility can be terminated via SIGTERM or similar).=0A= =0A= I am on the fence w.r.t. since I modelled it after the Linux one and keepin= g=0A= it Linux compatible would facilitate portable code, but I understand why=0A= Alan Somers wants to extend it (the iSCSI support seems particularily usefu= l).=0A= =0A= Everyone, please comment on this, rick=0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTBPR01MB3966966F82008C9E471708FCDD370>