From owner-svn-src-head@freebsd.org Sat May 5 00:26:47 2018 Return-Path: Delivered-To: svn-src-head@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 98D3FFBDD39 for ; Sat, 5 May 2018 00:26:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 009D07945A for ; Sat, 5 May 2018 00:26:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22a.google.com with SMTP id e20-v6so27591389iof.4 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=HHYtdQLVMXX/3KfHnEUmz5TghvtEVXZ2GB47GrEJrjymquolK+b0XuvHq4mrR2miIK 7h01e5wc1+AOShuPBrog16J0BB05X0wXiWWDWHUM4jaA/OeOhZsfzpWpe/av3NKU0YxO E/InYUYQ5Y1xItTZ8ppyonYRV72S3Fo/ARbjt1h31sm9SLnntKe+vc2RfFccAzMxXb6a k4hajHNZJUFczc5psRdGZr/5m9Z0DxyZ8LbF6YWIPDQO7A6w8fLwU9nfrE1IdU01/JNC 0rh6xIZtuwQUZz9YV5qNbmKXPClxVUGrDyrv5jnVsjXdvkxvB/Dm5wC/LXirzZFv/oEd No+g== X-Gm-Message-State: ALQs6tD1iXKQMluu7CuG2NbkEjdZhOdMh5Jj8dmrAJ8yrITQeJ/rnd1o WEfJUsrA/n/FKYcQCz3NP4aWjhLJ1SAKATypVtwjlA== 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-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current 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