From owner-svn-src-head@FreeBSD.ORG Sat May 23 10:01:11 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33CAB106567D for ; Sat, 23 May 2009 10:01:11 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outP.internet-mail-service.net (outp.internet-mail-service.net [216.240.47.239]) by mx1.freebsd.org (Postfix) with ESMTP id 128408FC1F for ; Sat, 23 May 2009 10:01:10 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id B2830DAF02; Sat, 23 May 2009 03:01:10 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id EFB2C2D6023; Sat, 23 May 2009 03:01:09 -0700 (PDT) Message-ID: <4A17C965.1090508@elischer.org> Date: Sat, 23 May 2009 03:01:09 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Robert Watson References: <200905222303.n4MN3Gsl021718@svn.freebsd.org> <20090522231117.F72053@maildrop.int.zabbadoz.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, "Bjoern A. Zeeb" , src-committers@freebsd.org Subject: Re: svn commit: r192612 - head/sys/netinet X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2009 10:01:13 -0000 Robert Watson wrote: > On Fri, 22 May 2009, Bjoern A. Zeeb wrote: > >> On Fri, 22 May 2009, Bjoern A. Zeeb wrote: >> >>> Author: bz >>> Date: Fri May 22 23:03:15 2009 >>> New Revision: 192612 >>> URL: http://svn.freebsd.org/changeset/base/192612 >>> >>> Log: >>> If including vnet.h one has to include opt_route.h as well. This is >>> because struct vnet_net holds the rt_tables[][] for MRT and array size >>> is compile time dependent. If you had ROUTETABLES set to >1 after >>> r192011 V_loif was pointing into nonsense leading to strange results >>> or even panics for some people. >>> >>> Reviewed by: mz >> >> Thanks to everyone who helped to debug this! > > This sounds like the sort of bug that will recur easily in the future, > as the double array based on configurable dimensions is not a very > robust structure in C. Is there something we can do to make this more > robust? For example, add assertions around consumers that appropriate > includes are present in those consumers? Also, given that it's a > compile-time option, rt_tables should probably be indirected to so that > there isn't an issue with modules compiled with different kernel > options? Especially network device drivers/modules that may need to use > vnet and be distributed as binary ko's? the approach taken in freebsd 7 and 6 for MRT was to allow for 100% backwards compatibility.. (A one dimensional array is just a degenerate case of a 2 dimensional array), however in 8.0 I can break the ABI so I'm tying to design a better way of doing this, possibly by moving to an array of pointers which in the MRT case would point to a vector of items but in the simple case to only a single item. Together with a method and some data in the domain structure, this might lead to a more flexible method that does not require pre-sized arrays. 7.x: ------ protocol family number---- ! [0][0][0][H][0][H][0][H][0][0][0][0] fib [0][0][0][H][0][0][0][H][0][0][0][0] ! [0][0][0][H][0][0][0][H][0][0][0][0] ! [0][0][0][H][0][0][0][H][0][0][0][0] where 'H' is a pointer to a fib 'tree' head 8.0 ------ protocol family number---- [0][0][0][.][0][.][0][.][0][0][0][0] | | | v v v [H] [H] [H] [H] [H] [H] [H] [H] [H] where [H] is a fib head pointer, and the domain struct for each protcol says show many elements there are for that protocol family in the vector. the end result is that what is eventually virtualised is fixed in size. thus rnh = V_rt_tables[fib][AF_INET] becomes rnh = (*V_rt_tables[AF_INET])[fib] where fib has previously been constrained to 0 in protocols where multiple fibs are not supported, and to 'maxfib(protocol)' otherwise. I'm open to other suggestions as well of course. but remember that netstat needs to be able to follow whatever we do on core dumps. > > Robert N M Watson > Computer Laboratory > University of Cambridge