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