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. > > > My opinion is that if we can make it work for character devices, we > should. > > 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). -AlanReceived on Sun Sep 27 2020 - 12:20:50 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:25 UTC