Date: Sun, 27 Sep 2020 02:52:40 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: "Wall, Stephen" <stephen.wall@redcom.com>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: Re: RFC: should copy_file_range(2) remain Linux compatible or support special files? Message-ID: <YTBPR01MB39663AB569A9B0EB8FF889F7DD340@YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <MN2PR09MB4876F76163F8DA9276486AF9EE340@MN2PR09MB4876.namprd09.prod.outlook.com> References: <YTBPR01MB3966966F82008C9E471708FCDD370@YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM>, <MN2PR09MB4876F76163F8DA9276486AF9EE340@MN2PR09MB4876.namprd09.prod.outlook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Wall, Stephen wrote: > Could the as yet unused options param have a bit assigned to trigger the new > behavior? Inform the linux community of the addition and let them decide if they > would like to adopt it as well. I'll assume you are referring to the "flags" argument when you say "param" above. You could. However, since the Linux man page says it will return EINVAL if the "flags" argument is non-zero, you've still introduced an incompatibility w.r.t. the Linux behaviour. It does make it clear that copy_file_range(2) will have the non-Linux behaviour when the flag is specified, which I think is a good idea. rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTBPR01MB39663AB569A9B0EB8FF889F7DD340>