On Fri, May 4, 2018 at 5:12 PM, Mateusz Guzik <mjgu...@gmail.com> wrote:
> On Sat, May 5, 2018 at 12:58 AM, Steven Hartland < > steven.hartl...@multiplay.co.uk> wrote: > >> Can we get the why in commit messages please? >> >> This sort of message doesnt provide anything more that can be obtained >> from reading the diff, which just leaves us wondering why? >> >> I’m sure there is a good reason, but without confirmation we’re just left >> guessing. The knock on to this is if some assumption that caused the why >> changes, anyone looking at this will not be able to make an informed >> descision that that was the case. >> >> > bcopy is an equivalent of memmove, i.e. it accepts overlapping buffers. > But if we know for a fact they don't overlap (like here), doing this over > memcpy (which does not accept such buffers) only puts avoidable > constraints on the optimizer. > bcopy, in userland, is memmove. bcopy in the kernel has had a more complicated history. Today it's more like memmove, but at times in the history of BSD/Unix it's be more akin to memcpy with a companion ovbcopy used for overlapping copies. FreeBSD has almost always been more in the 'bcopy is memmove' rather than the 'bcopy is memcpy' though some of the lower-tier architectures pulled in ovbcopy which we recently GC'd from NetBSD and/or OpenBSD. Plus there's been an irrational encouragement of using bcopy over mem* which has lead to the current state of affairs. For the vast majority of uses, it hasn't really mattered much in the past. It hasn't shown up on radar. However, as its optimization has moved into the compiler I'm guessing that's changed. It's that change of heart I think that are taking people by surprise. Warner _______________________________________________ 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"
