Date: Sat, 23 May 2009 13:21:22 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, "Bjoern A. Zeeb" <bz@FreeBSD.org>, src-committers@FreeBSD.org Subject: Re: svn commit: r192612 - head/sys/netinet Message-ID: <alpine.BSF.2.00.0905231317160.75344@fledge.watson.org> In-Reply-To: <20090523213159.Y848@delplex.bde.org> References: <200905222303.n4MN3Gsl021718@svn.freebsd.org> <20090522231117.F72053@maildrop.int.zabbadoz.net> <alpine.BSF.2.00.0905230909170.75344@fledge.watson.org> <20090523213159.Y848@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 23 May 2009, Bruce Evans wrote: > For a single option that spams a header like this one, it is probably easy > to check it using ifdefs. <net/route.h> must not define RT_MAXFIBS unless > opt_mroute.h has been included. AT least this option header would have to > always #define something to identify itself for this check to be possible. > The include should not be in <net/route.h> to inhibit growth of this bug and > corresponding pollution. IIRC, bz removed it from there as a start to > fixing this. <net/vnet.h> still imncludes <net/if_var.h> which includes an > enormous amount of pollution. > >> 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? > > They aren't modules if they are affected by kernel options :-). > > Aren't there problems with this, else it would have been done. The problem is that VIMAGE makes the problem of changing sizes in global variables much worse by packing global variables together at varying offsets from a single symbol, rather than having different symbols for different globals. This means that any errant resizing of a global (such as changing structure layout) affects the binary interface for modules that depend on globals that appear later in that packing. We're probably stuck with this direction for now in order to get virtualization functionality, but what it means is that it is *critical* that no global data structure embedded directly in these packing structures be resized. Anything that might be resized, especially as a result of a kernel option, must be pointed to indirectly so that other global (per-vimage) variables can still be addressed safely. Other strategies for maintaining globals in a more robust, less indirection-prone but still virtualization-friendly way would be most welcome... Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0905231317160.75344>