On 2019-06-15 11:59, Marius Strobl wrote:
On Sat, Jun 15, 2019 at 09:08:05AM -0400, Andrew Gallatin wrote:
On 2019-06-15 07:07, Marius Strobl wrote:
Author: marius
Date: Sat Jun 15 11:07:41 2019
New Revision: 349055

Log:
    - Replace unused and only ever written to members of public iflib(9)
      structs with placeholders (in the latter case, IFLIB_MAX_TX_BYTES
      etc. are also only ever used for these write-only members if at all,
      so both these macros and members can just go). Using these spares
      may render it possible to merge certain iflib(9) fixes to stable/12.
      Otherwise, changes extending struct if_irq or struct if_shared_ctx
      in any way would break KBI as instances of these are allocated by
      the driver front-ends (by contrast, struct if_pkt_info as well as
      struct if_softc_ctx instances are provided by iflib(9) and, thus,
      may grow at least at the end without breaking KBI).

Given the above, why replace ipi_tcp_sum in if_pkt_info with a spare?
Given that if_pkt_info can grow, I would also expect it to be able to
shrink.  So I don't quite see why the spare is needed here.

I also worry about carrying the other spares around forever.

Yes, KBI-wise it should be also safe for instances of structures allocated
by iflib(9) to shrink at the end (though shrinking structures usually isn't
a concern when MFCing as such parts may just be omitted); changes altering
the offsets of members would be a problem regarding KBI.
Still, I don't like changing the size of publicly visible structures in
stable branches without a real good reason even if such a change doesn't
strictly break the KBI. So the plan is to MFC the spares but then to get
rid of the ones whose removal doesn't break KBI in head.

Marius


Thanks, that makes sense

Drew
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Reply via email to