svn commit: r192612 - head/sys/netinet

[Bruce Evans]

On Sat, 23 May 2009, Robert Watson wrote:

> On Fri, 22 May 2009, Bjoern A. Zeeb wrote:
>
>> On Fri, 22 May 2009, Bjoern A. Zeeb wrote:
>>> ...
>>> 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?

I tried to think of a way to do this automatically for all options headers,
but couldn't do it.  `#if[n]def' will just always do something.  The option
testing could have to be written as something like `#if opt(...)', but that
is far from automatic and almost as error-prone.

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.

Bruce