RFC: should copy_file_range(2) remain Linux compatible or support special files?

[Rick Macklem]

Mateusz Guzik wrote:
>On 9/27/20, Alan Somers <asomers at freebsd.org> wrote:
>> On Sun, Sep 27, 2020 at 7:49 AM Wall, Stephen <stephen.wall at redcom.com>
>> wrote:
>>
>>>
>>> > I'll assume you are referring to the "flags" argument when you say
>>> "param" above.
>>>
>>> Correct, I was misremembering the man page.
>>>
>>> > 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.
>>>
>>> This would be a one-way incompatibility, i.e. code written on linux will
>>> run unaltered on FreeBSD.
>>> If the flag were along the lines of `FREEBSD_COPY_DEVICES` (or whatever,
>>> important part is `FREEBSD`) it will be quite obvious that this code
>>> needs
>>> to be adapted to other platforms:
>>> ```
>>> #ifndef FREEBSD_COPY_DEVICES
>>> #define FREEBSD_COPY_DEVICES 0
>>> #endif
>>> ```
>>>
>>> > Why require extra work for so little purpose?
>>>
>>> I'm sorry, I'm not sure what extra work you are referring to.  Specifying
>>> a flag on copy_file_range(2)?  That's trivial.
>>>
>>
>> It's easy to leave out, which could cause a lot of pain for users who don't
>> understand why their application isn't working.
>>
>
>A FreeBSD-specific flag to a Linux-alike syscall is bound to run into
>a conflict at some point, making it a non-starter.
>
>>
>>>
>>> > My opinion is that if we can make it work for character devices, we
>>> should.
This turns out to be a lot messier than I thought it would be.
For example: /dev/zero cannot be read via VOP_READ() on the vnode.
To read it, you must us dofileread() on the file descriptor.
--> This implies a separate copy loop from the one implemented by
    vn_generic_copy_file_range(), which works on vnodes. (And that needs to
    remain, because the NFS server only has vnodes and no open file descriptors.

At least that appears to be the case when I tried it and then looked in
sys/fs/devfs and sys/dev/null when it didn't work.

rick

>>
>> Well, collecting opinions was the point, no? :)
>>
>> What's going to use this function besides system commands?  I think I saw
>> `cp` and `dd` mentioned - I think it unlikely you need to be concerned
>> about their portability.
>>
>
> Userspace RAID-like applications could use it for rebuilds, and they'll
> need it to work on device nodes.  Userspace NFS servers and iSCSI servers
> could obviously use it.  And since the FUSE protocol includes a
> COPY_FILE_RANGE operation, many FUSE daemons could implement that with
> copy_file_range(2).

I think the first thing to do is check what Linux is doing here, most
notably they may have other primitives to take care of it and in that
case would be best to implement equivalents.

I don't have a strong opinion on VCHR support. I will note there may
be Linux code expecting to fail with such argument.

If Linux-compatible approach mentioned above is not going to work out,
I think the best thing to do is to add another syscall
(copy_file_range_np?) which can be tweaked however we see fit.

--
Mateusz Guzik <mjguzik gmail.com>