From owner-svn-src-stable@freebsd.org Wed Mar 7 20:01:26 2018 Return-Path: Delivered-To: svn-src-stable@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 B48B1F2B4AE; Wed, 7 Mar 2018 20:01:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5A1066B1BC; Wed, 7 Mar 2018 20:01:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 5A87810A87D; Wed, 7 Mar 2018 15:01:25 -0500 (EST) From: John Baldwin To: Eitan Adler Cc: src-committers , svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-11@freebsd.org Subject: Re: svn commit: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211 Date: Wed, 07 Mar 2018 09:37:16 -0800 Message-ID: <8377086.JrIgVVMXMv@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: References: <201803050754.w257swAE001435@repo.freebsd.org> <6465173.s2nWvWCLOs@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Wed, 07 Mar 2018 15:01:25 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 20:01:26 -0000 On Tuesday, March 06, 2018 06:46:37 PM Eitan Adler wrote: > On 6 March 2018 at 08:26, John Baldwin wrote: > > On Monday, March 05, 2018 07:13:59 PM Eitan Adler wrote: > >> On 5 March 2018 at 10:08, John Baldwin wrote: > >> > On Monday, March 05, 2018 07:54:58 AM Eitan Adler wrote: > >> >> Author: eadler > >> >> Date: Mon Mar 5 07:54:57 2018 > >> >> New Revision: 330451 > >> >> URL: https://svnweb.freebsd.org/changeset/base/330451 > >> >> > >> >> Log: > >> >> MFC r306837: > >> >> > >> >> [net80211] extend the ieee80211_rx_stats struct to include more information. > >> > > >> > Have you thought about the KBI implications of this change and some of the > >> > other changes you've merged? > >> > >> I do have a copy of the modules from 11.1 and have loaded them at > >> various points in time after merging. That said, I am not perfect. > >> Unfortunately, my -STABLE box did not have fully functioning drivers > >> before these changes so its difficult to test anything beyond "loads > >> and does not panic.". I havn't done so today yet, but that will happen > >> soon. > >> > >> Ensuring these things work through code inspection is certainly > >> possible and I've skipped over several changes as a result. > > > > Loading a module doesn't alone doesn't actually test for breakage. > > I'm aware. In this case I should likely just revert this change since > its a pretty blatant break. I suspect many of these changes for iwm, etc. are all intertwined so I'm not sure if you can leave out individual ones. > > Batching > > up changes into a single diff is also helpful since if an API changes back > > and forth in HEAD multiple times, collapsing them means that for stable you > > may only need a single compat shim rather than several. > > Understood. My intention in doing them one-by-one was to make it > easier to bisect if something goes wrong. For stable I think we also want to balance this with: 1) Not putting stable in a known-broken state. If there are followup fixes either for compile or runtime performances, those followup fixes should always be included in the commit that merges the original change. 2) Preserving ABI. The desire to avoid putting stable into known-broken state means that MFCs should include the ABI shims along with the original change. -- John Baldwin