RFC: should copy_file_range(2) remain Linux compatible or support special files?
Wall, Stephen
stephen.wall at redcom.com
Sun Sep 27 13:49:23 UTC 2020
> 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.
> 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.
-spw
More information about the freebsd-hackers
mailing list