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>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2jiHAgMXRNpMU%2B5aYoJmbBDE206cfZ50iE-0gNMAXVuLw>