> > +A major rework of the kernel implementation occurred in 5.3. Areas of the API > > +that weren't clearly defined were clarified and the API bounds are much more > > +strictly checked than on earlier kernels. Applications should target the > > +behaviour and requirements of 5.3 kernels. > > Are there any weird cases where a program targetting 5.3 behavior would > fail or get stuck in an infinite loop on a 5.2 kernel? I don't think so. When Dave wrote this paragraph the behavior was changed from short copy to EINVAL. That would have been a problem to maintain old vs. new copy loops, but now the behavior did not change in that respect. > > Particularly since glibc spat out a copy_file_range fallback for 2.29 > that tries to emulate the kernel behavior 100%. It even refuses > cross-filesystem copies (because hey, we documented that :() even though > that's perfectly fine for a userspace implementation. > > TBH I suspect that we ought to get the glibc developers to remove the > "no cross device copies" code from their implementation and then update > the manpage to say that cross device copies are supposed to be > supported all the time, at least as of glibc 2.(futureversion). I don't see a problem with copy_file_range() returning EXDEV. That is why I left EXDEV in the man page. Tools should know how to deal with EXDEV by now. If you are running on a new kernel, you get better likelihood for copy_file_range() to do clone or in-kernel copy for you. > > Anyways, thanks for taking on the c_f_r cleanup! :) > Sure, get ready for another round ;-) Thanks for the review! Amir.
