From owner-svn-src-all@freebsd.org Sat May 5 00:26:47 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 93F34FBDD38 for ; Sat, 5 May 2018 00:26:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 03DB77945D for ; Sat, 5 May 2018 00:26:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x234.google.com with SMTP id c9-v6so21222980iob.12 for ; Fri, 04 May 2018 17:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Sv0St9+nqGs1hYTvKmCWqU2P70RuVR5eJqFyGtL14rA=; b=H3sIzoPG8DN0wahdnoGVTivNQ0dBsbLyEMG5IQ5SVkMoKylHDWl/rI5SzjlPHPIdCd dHrxLgarr1Xj08dyJAUkfarrKXqWrc9xLfGlN49Yl6kdAf99qB9l6mt/a0flrjAmJApz 1Hkmgtx7K7fNKgefL6GxDYMYrMCfCQePr32PFyb9ERUg0gOzClz7kRpeGIWwjTy5tN0L qhz8/NWVm3/jFEft4B/QOVT1ziUpgQuxkG43KdPsHk248OKuV9VCYSxxLX7DrQwbOTr6 H7I+JjHtltdvqOaHsClnHVvlvUvVidkxg+FxGB0o9zdxeXcnAkaHpf3vm7MtYn5J3uWY G5Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Sv0St9+nqGs1hYTvKmCWqU2P70RuVR5eJqFyGtL14rA=; b=aihN20Ky0fevgpDdhd76R7mf3STnh0ZngzKHeLaPbEVtvl22np36n1ul/LUoJJPPiV +W8R2lj6M9QJPG6xDFgXNCm8C3fylllQ5RP9J9tKp9dcDE7zB2WRULCt4VtwzO31xm0I qs101/FC5lzgrt7qZ0rvo35sx/Dbk224RGRaxXKpMUXrkSXrwTLP8Wzh4dGXo/NbU5U/ UVkyhcfCdoFnQglUb78nBqHGIysEYqk1gNt5gMFMHykpU5uifaCrjNlRLciq7SZLvM2o +pg1sTX9iQCUCvwtLlGi0z/vaR3KiHEm0UT5zmjqIRqQw+MbX9LdRnuQEXYSly4IvDoI WnjA== X-Gm-Message-State: ALQs6tA7N735CX2AW0tOEHIPRp6zRjV2BQ/HIDmDxhZ2dRot6JFsbd1p 7zCRrKc43a4T7Dvgc8LQZZMpQy96ti1XCGkOCsSuVQ== X-Google-Smtp-Source: AB8JxZqOv0dYXLxYkL/9fKHPhOzVQIxUs8oDVkD3bzMM9PbA/arGkF/ZJAgyqFNDWeIFqzKcaa6XMeGrpyqDEE+mhDU= X-Received: by 2002:a6b:d404:: with SMTP id l4-v6mr31993702iog.37.1525480006209; Fri, 04 May 2018 17:26:46 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:a65a:0:0:0:0:0 with HTTP; Fri, 4 May 2018 17:26:45 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <201805042241.w44MfC9E090893@repo.freebsd.org> From: Warner Losh Date: Fri, 4 May 2018 18:26:45 -0600 X-Google-Sender-Auth: ibXL-8sv6U6ipV7aq35zy55yf7M Message-ID: Subject: Re: svn commit: r333266 - head/sys/amd64/amd64 To: Mateusz Guzik Cc: Steven Hartland , Mateusz Guzik , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2018 00:26:47 -0000 On Fri, May 4, 2018 at 5:12 PM, Mateusz Guzik 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. > 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