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

On Sat, Sep 26, 2020 at 8:52 PM Rick Macklem <rmacklem_at_uoguelph.ca> wrote:

> Wall, Stephen wrote:
> > Could the as yet unused options param have a bit assigned to trigger the
> new
> > behavior?  Inform the linux community of the addition and let them
> decide if they
> > would like to adopt it as well.
> I'll assume you are referring to the "flags" argument when you say "param"
> above.
>
> You could. 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.
> It does make it clear that copy_file_range(2) will have the non-Linux
> behaviour
> when the flag is specified, which I think is a good idea.
>

I think it's just syntactic salt.  Why require extra work for so little
purpose?  My opinion is that if we can make it work for character devices,
we should.