Date: Fri, 4 May 2018 16:44:09 -0700 From: Juli Mallett <juli@northcloak.com> To: Mateusz Guzik <mjguzik@gmail.com> Cc: Steven Hartland <steven.hartland@multiplay.co.uk>, Mateusz Guzik <mjg@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r333266 - head/sys/amd64/amd64 Message-ID: <CAGSiXYwVk3-%2B6XY_w=E8O1V7AGXbdOpuSwCrgxgqw-p2R4Mujg@mail.gmail.com> In-Reply-To: <CAGudoHFDNLsMxKz9nY%2BvsOm66=7W0gd1-BBwi5ABEwOGiLvDbQ@mail.gmail.com> References: <201805042241.w44MfC9E090893@repo.freebsd.org> <CAHEMsqbybV8%2BYO2rE8BqbTKspqf_xVGKcH_vKJE-b3NFmuQCDA@mail.gmail.com> <CAGudoHFDNLsMxKz9nY%2BvsOm66=7W0gd1-BBwi5ABEwOGiLvDbQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4 May 2018 at 16:12, Mateusz Guzik <mjguzik@gmail.com> wrote: > On Sat, May 5, 2018 at 12:58 AM, Steven Hartland < > steven.hartland@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=E2=80=99m sure there is a good reason, but without confirmation we=E2= =80=99re 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. > > This is a rather pedestrian change which can be made in many places, > I don't see the point of repeating the explanation in each one. Although > I guess it would make sense to point at a specific commit which explains > things. > I feel like the second paragraph in particular suggests a methodical project (maybe in a branch?) to convert or mark all instances as not-to-be-converted based on their context and practical concerns (like performance) might be better than doing a bunch of one-off commits, with batched commits to -CURRENT from time-to-time. Then it's easy to say "Phase IV of bcopy analysis in kernel: convert to memcpy for all non-overlapping small copies" with a whole bunch of changes lumped together= .
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGSiXYwVk3-%2B6XY_w=E8O1V7AGXbdOpuSwCrgxgqw-p2R4Mujg>