RFC: copy_file_range(3)

[Rick Macklem]

Alan Somers wrote:
>copy_file_range(2) is nifty, but it has a few sharp edges:
>1) Certain file systems don't support it, necessitating a write/read based
>fallback
>2) It doesn't handle sparse files as well as SEEK_HOLE/SEEK_DATA
>3) It's slightly tricky to both efficiently deal with holes and also
>promptly respond to signals
>
>These problems aren't terribly hard, but it seems to me like most
>applications that use copy_file_range would share the exact same
>solutions.  In particular, I'm thinking about cp(1), dd(1), and
>install(8).  Those three could benefit from sharing a userland wrapper that
>handles the above problems.
>
>Should we add such a wrapper to libc?  If so, what should it be called, and
>should it be public or just private to /usr/src ?
There has been a discussion on src-committers which I suggested should
be taken to a public mailing list.

The basic question is...
Whether or not the copy_file_range(2) syscall should be compatible with
the Linux one.
When I did the syscall, I tried to make it Linux-compatible, arguing that
Linux is now a de-facto standard.
The Linux syscall only works on regular files, which is why Alan's patch for
cp required a "fallback to the old way" for VCHR files like /dev/null.

He is considering a wrapper in libc to provide FreeBSD specific semantics,
which I have no problem with, so long as the naming and man page make
it clear that it is not compatible with the Linux syscall.
(Personally, I'd prefer a wrapper in libc to making the actual syscall non-Linux
 compatible, but that is just mho.)

Hopefully this helps clarify what Alan is asking, rick

-Alan
_______________________________________________
freebsd-hackers at freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"