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:=0A= > Could the as yet unused options param have a bit assigned to trigger the = new =0A= > behavior? Inform the linux community of the addition and let them decide= if they=0A= > would like to adopt it as well.=0A= I'll assume you are referring to the "flags" argument when you say "param" = above.=0A= =0A= You could. However, since the Linux man page says it will return EINVAL if= =0A= the "flags" argument is non-zero, you've still introduced an incompatibilit= y=0A= w.r.t. the Linux behaviour.=0A= It does make it clear that copy_file_range(2) will have the non-Linux behav= iour=0A= when the flag is specified, which I think is a good idea.=0A= =0A= rick=0A= =0A= =0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTBPR01MB39663AB569A9B0EB8FF889F7DD340>