Date: Sat, 15 Jun 2019 14:48:30 -0400 From: Andrew Gallatin <gallatin@cs.duke.edu> To: Marius Strobl <marius@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r349055 - head/sys/net Message-ID: <178554f8-27f4-d09c-0d6f-0f53febbf601@cs.duke.edu> In-Reply-To: <20190615155940.GM6782@alchemy.franken.de> References: <201906151107.x5FB7f6N039968@repo.freebsd.org> <154077cb-14b1-1dbc-cb65-3233045963c0@cs.duke.edu> <20190615155940.GM6782@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?178554f8-27f4-d09c-0d6f-0f53febbf601>