svn commit: r349055 - head/sys/net

Andrew Gallatin gallatin at cs.duke.edu
Sat Jun 15 18:48:33 UTC 2019


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


More information about the svn-src-head mailing list