From owner-svn-src-stable@FreeBSD.ORG Fri Jan 7 05:34:51 2011 Return-Path: Delivered-To: svn-src-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46B3A106566B; Fri, 7 Jan 2011 05:34:51 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id D2FBE8FC08; Fri, 7 Jan 2011 05:34:50 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id D95BB7E8BA; Fri, 7 Jan 2011 16:15:17 +1100 (EST) Message-ID: <4D26A165.3070001@freebsd.org> Date: Fri, 07 Jan 2011 16:15:17 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101215 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "George V. Neville-Neil" References: <201101051852.p05IqUjK087769@svn.freebsd.org> In-Reply-To: <201101051852.p05IqUjK087769@svn.freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Cc: src-committers@FreeBSD.org, svn-src-stable@FreeBSD.org, svn-src-all@FreeBSD.org, "Bjoern A. Zeeb" , svn-src-stable-8@FreeBSD.org, "Robert N. M. Watson" Subject: Re: svn commit: r217018 - stable/8/sys/netinet X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 05:34:51 -0000 Hi George, On 01/06/11 05:52, George V. Neville-Neil wrote: > Author: gnn > Date: Wed Jan 5 18:52:30 2011 > New Revision: 217018 > URL: http://svn.freebsd.org/changeset/base/217018 > > Log: > Fix binary compatability for netstats across the -x/-T changes > that have been previously MFC'd. > > Reviewed by: rwatson, bz > > Modified: > stable/8/sys/netinet/tcp_var.h > > Modified: stable/8/sys/netinet/tcp_var.h > ============================================================================== > --- stable/8/sys/netinet/tcp_var.h Wed Jan 5 18:46:05 2011 (r217017) > +++ stable/8/sys/netinet/tcp_var.h Wed Jan 5 18:52:30 2011 (r217018) > @@ -177,7 +177,6 @@ struct tcpcb { > u_long snd_cwnd_prev; /* cwnd prior to retransmit */ > u_long snd_ssthresh_prev; /* ssthresh prior to retransmit */ > tcp_seq snd_recover_prev; /* snd_recover prior to retransmit */ > - int t_sndzerowin; /* zero-window updates sent */ > u_int t_badrxtwin; /* window for retransmit recovery */ > u_char snd_limited; /* segments limited transmitted */ > /* SACK related state */ > @@ -194,14 +193,15 @@ struct tcpcb { > u_int32_t rfbuf_ts; /* recv buffer autoscaling timestamp */ > int rfbuf_cnt; /* recv buffer autoscaling byte count */ > struct toe_usrreqs *t_tu; /* offload operations vector */ > - int t_sndrexmitpack; /* retransmit packets sent */ > - int t_rcvoopack; /* out-of-order packets received */ > void *t_toe; /* TOE pcb pointer */ > int t_bytes_acked; /* # bytes acked during current RTT */ > > - int t_ispare; /* explicit pad for 64bit alignment */ > + int t_sndzerowin; /* zero-window updates sent */ > + uint64_t t_sndrexmitpack;/* retransmit packets sent */ > + uint64_t t_rcvoopack; /* out-of-order packets received */ > + > void *t_pspare2[6]; /* 2 CC / 4 TBD */ > - uint64_t _pad[12]; /* 7 UTO, 5 TBD (1-2 CC/RTT?) */ > + uint64_t _pad[10]; /* 7 UTO, 3 TBD (1-2 CC/RTT?) */ > }; On my stable/8 machine after updating world but not kernel I see "struct xtcpcb size mismatch" messages which indicates the ABI has been futzed with. Looking at the above diff I think this commit does indeed change the ABI and therefore needs to be tweaked in order to maintain our current ABI preservation policy for stable branches (unless I'm missing something?). If the change to the ABI is intentional, a note in UPDATING would probably be warranted. Cheers, Lawrence