Date: Sat, 26 Sep 2020 20:55:41 -0600 From: Alan Somers <asomers@freebsd.org> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: "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: <CAOtMX2jiHAgMXRNpMU%2B5aYoJmbBDE206cfZ50iE-0gNMAXVuLw@mail.gmail.com> In-Reply-To: <YTBPR01MB39663AB569A9B0EB8FF889F7DD340@YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM> References: <YTBPR01MB3966966F82008C9E471708FCDD370@YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM> <MN2PR09MB4876F76163F8DA9276486AF9EE340@MN2PR09MB4876.namprd09.prod.outlook.com> <YTBPR01MB39663AB569A9B0EB8FF889F7DD340@YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Sep 26, 2020 at 8:52 PM Rick Macklem <rmacklem@uoguelph.ca> wrote: > 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. > I think it's just syntactic salt. Why require extra work for so little purpose? My opinion is that if we can make it work for character devices, we should.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2jiHAgMXRNpMU%2B5aYoJmbBDE206cfZ50iE-0gNMAXVuLw>