svn commit: r330451 - in stable/11/sys: dev/iwm dev/otus dev/usb/wlan net80211

John Baldwin jhb at freebsd.org
Wed Mar 7 20:01:26 UTC 2018


On Tuesday, March 06, 2018 06:46:37 PM Eitan Adler wrote:
> On 6 March 2018 at 08:26, John Baldwin <jhb at freebsd.org> wrote:
> > On Monday, March 05, 2018 07:13:59 PM Eitan Adler wrote:
> >> On 5 March 2018 at 10:08, John Baldwin <jhb at freebsd.org> 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


More information about the svn-src-all mailing list