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

>   It also tends to be a lot harder to find these
> breakages in code one didn't write.

This is true

> I think for net80211 you need to generate a diff of all of the wireless
> related changes you have MFC'd to stable/11 and then review that for ABI
> changes and come up with a plan for how to restore the ABI and get re@'s
> approval.  (kib@ is a pretty good resource for devising ABI shims.)

I'll take a look to see what else I broke / changed and either revert
or write up a shim. Thanks!

> 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.

Eitan Adler
Source, Ports, Doc committer
Bugmeister, Ports Security teams
svn-src-all@freebsd.org mailing list
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Reply via email to