svn commit: r192612 - head/sys/netinet

[Robert Watson]

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