svn commit: r192612 - head/sys/netinet
rwatson at FreeBSD.org
Sat May 23 12:21:23 UTC 2009
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
Robert N M Watson
University of Cambridge
More information about the svn-src-all