Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 15 Jun 2019 09:08:05 -0400
From:      Andrew Gallatin <gallatin@cs.duke.edu>
To:        Marius Strobl <marius@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r349055 - head/sys/net
Message-ID:  <154077cb-14b1-1dbc-cb65-3233045963c0@cs.duke.edu>
In-Reply-To: <201906151107.x5FB7f6N039968@repo.freebsd.org>
References:  <201906151107.x5FB7f6N039968@repo.freebsd.org>

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

Drew



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?154077cb-14b1-1dbc-cb65-3233045963c0>