Date: Fri, 2 Oct 2020 04:25:10 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Mateusz Guzik <mjguzik@gmail.com>, Alan Somers <asomers@freebsd.org> 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: <YTBPR01MB39668F45B738368C6E409FABDD310@YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <CAGudoHGPPpwZRm=w3AGGBzxVwEWrMWpr6d%2B4S2gtnArwAc14RA@mail.gmail.com> References: <YTBPR01MB3966966F82008C9E471708FCDD370@YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM> <MN2PR09MB4876F76163F8DA9276486AF9EE340@MN2PR09MB4876.namprd09.prod.outlook.com> <YTBPR01MB39663AB569A9B0EB8FF889F7DD340@YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM> <MN2PR09MB487615BB0445AA7F9BC91066EE340@MN2PR09MB4876.namprd09.prod.outlook.com> <CAOtMX2gR7JaEx%2BswXfe1y0zU_V3PggGQ-UvU%2BY4yPiApmcZHzg@mail.gmail.com>, <CAGudoHGPPpwZRm=w3AGGBzxVwEWrMWpr6d%2B4S2gtnArwAc14RA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mateusz Guzik wrote:=0A=
>On 9/27/20, Alan Somers <asomers@freebsd.org> wrote:=0A=
>> On Sun, Sep 27, 2020 at 7:49 AM Wall, Stephen <stephen.wall@redcom.com>=
=0A=
>> wrote:=0A=
>>=0A=
>>>=0A=
>>> > I'll assume you are referring to the "flags" argument when you say=0A=
>>> "param" above.=0A=
>>>=0A=
>>> Correct, I was misremembering the man page.=0A=
>>>=0A=
>>> > However, since the Linux man page says it will return EINVAL if=0A=
>>> > the "flags" argument is non-zero, you've still introduced an=0A=
>>> incompatibility=0A=
>>> > w.r.t. the Linux behaviour.=0A=
>>>=0A=
>>> This would be a one-way incompatibility, i.e. code written on linux wil=
l=0A=
>>> run unaltered on FreeBSD.=0A=
>>> If the flag were along the lines of `FREEBSD_COPY_DEVICES` (or whatever=
,=0A=
>>> important part is `FREEBSD`) it will be quite obvious that this code=0A=
>>> needs=0A=
>>> to be adapted to other platforms:=0A=
>>> ```=0A=
>>> #ifndef FREEBSD_COPY_DEVICES=0A=
>>> #define FREEBSD_COPY_DEVICES 0=0A=
>>> #endif=0A=
>>> ```=0A=
>>>=0A=
>>> > Why require extra work for so little purpose?=0A=
>>>=0A=
>>> I'm sorry, I'm not sure what extra work you are referring to. Specifyi=
ng=0A=
>>> a flag on copy_file_range(2)? That's trivial.=0A=
>>>=0A=
>>=0A=
>> It's easy to leave out, which could cause a lot of pain for users who do=
n't=0A=
>> understand why their application isn't working.=0A=
>>=0A=
>=0A=
>A FreeBSD-specific flag to a Linux-alike syscall is bound to run into=0A=
>a conflict at some point, making it a non-starter.=0A=
>=0A=
>>=0A=
>>>=0A=
>>> > My opinion is that if we can make it work for character devices, we=
=0A=
>>> should.=0A=
This turns out to be a lot messier than I thought it would be.=0A=
For example: /dev/zero cannot be read via VOP_READ() on the vnode.=0A=
To read it, you must us dofileread() on the file descriptor.=0A=
--> This implies a separate copy loop from the one implemented by=0A=
vn_generic_copy_file_range(), which works on vnodes. (And that needs to=
=0A=
remain, because the NFS server only has vnodes and no open file descrip=
tors.=0A=
=0A=
At least that appears to be the case when I tried it and then looked in=0A=
sys/fs/devfs and sys/dev/null when it didn't work.=0A=
=0A=
rick=0A=
=0A=
>>=0A=
>> Well, collecting opinions was the point, no? :)=0A=
>>=0A=
>> What's going to use this function besides system commands? I think I sa=
w=0A=
>> `cp` and `dd` mentioned - I think it unlikely you need to be concerned=
=0A=
>> about their portability.=0A=
>>=0A=
>=0A=
> Userspace RAID-like applications could use it for rebuilds, and they'll=
=0A=
> need it to work on device nodes. Userspace NFS servers and iSCSI servers=
=0A=
> could obviously use it. And since the FUSE protocol includes a=0A=
> COPY_FILE_RANGE operation, many FUSE daemons could implement that with=0A=
> copy_file_range(2).=0A=
=0A=
I think the first thing to do is check what Linux is doing here, most=0A=
notably they may have other primitives to take care of it and in that=0A=
case would be best to implement equivalents.=0A=
=0A=
I don't have a strong opinion on VCHR support. I will note there may=0A=
be Linux code expecting to fail with such argument.=0A=
=0A=
If Linux-compatible approach mentioned above is not going to work out,=0A=
I think the best thing to do is to add another syscall=0A=
(copy_file_range_np?) which can be tweaked however we see fit.=0A=
=0A=
--=0A=
Mateusz Guzik <mjguzik gmail.com>=0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTBPR01MB39668F45B738368C6E409FABDD310>