Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 15 Jun 2019 17:59:40 +0200
From:      Marius Strobl <marius@freebsd.org>
To:        Andrew Gallatin <gallatin@cs.duke.edu>
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:  <20190615155940.GM6782@alchemy.franken.de>
In-Reply-To: <154077cb-14b1-1dbc-cb65-3233045963c0@cs.duke.edu>
References:  <201906151107.x5FB7f6N039968@repo.freebsd.org> <154077cb-14b1-1dbc-cb65-3233045963c0@cs.duke.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190615155940.GM6782>