svn commit: r333266 - head/sys/amd64/amd64

Warner Losh imp at bsdimp.com
Sat May 5 00:26:47 UTC 2018


On Fri, May 4, 2018 at 5:12 PM, Mateusz Guzik <mjguzik at gmail.com> wrote:

> On Sat, May 5, 2018 at 12:58 AM, Steven Hartland <
> steven.hartland at 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


More information about the svn-src-head mailing list