On Sat, May 5, 2018 at 2:00 PM, Alexey Dokuchaev <da...@freebsd.org> wrote:
> On Sat, May 05, 2018 at 10:38:29AM +1000, Bruce Evans wrote: > > ... > > Summary: this change wouldn't have passed my review. I have used similar > > changes for 15-20 years but never made them production quality since > there > > are too many variations to consider and testing showed insignificant > > improvements except for micro-benchmarks. > > Perhaps Foundation could sponsor your work to make them production quality > Bruce. :-) > > Seriously though, I'm a bit worried to see these commits happening at the > same time correctness of the implementation is still under discussion and > disputes. Shall I expect that after my next -CURRENT update things would > suddenly stop working? [1] > > ./danfe > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=638477 > > Nothing of the sort was done here. They had a memcpy function which internally behaved like memmove. They changed to behave like mere memcpy (i.e. assume non-overlapping buffers). This caused buggy code to run into trouble. bcopy has memmove semantics and this change keeps that. The only difference is that instead of always generating a call, the compiler is allowed to perform the copy in place in certain cases. This is precisely what happens almost everywhere and it was not happening in the kernel because of a giant hammer -fno-builtin flag (added to reduce changes the compiler will do stuff the kernel does not want to deal with). -- Mateusz Guzik <mjguzik gmail.com> _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
