HEADS UP: vimage - virtualized global variables in the network stack

Bjoern A. Zeeb bz at FreeBSD.org
Sat Dec 13 20:10:07 UTC 2008

On Sat, 13 Dec 2008, Max Laier wrote:

> On Saturday 13 December 2008 20:33:53 Bjoern A. Zeeb wrote:
> ...
>> This state of having the variables in parallel, global and in the
>> container struct, will be maintained for another (short) time until
>> the entire virtualization framework is in. This is needed, so that
>> all three possible states can be benchmarked from exactly the same
>> code changeset.
>> For developers comitting new code or changing code it is important to
>> properly add virtualized variables in the way that:
>> 1) the globals and externs (if needed) are added/kept in sync as both
>>     a) globals under #ifdef VIMAGE_GLOBALS and b) to the appropriate
>>     container struct + the V_ macro.
>>     When used somewhere in code one has to use the V_foobarbaz version.
> Is there (an easy) way to have the tinderbox build every other run without
> VIMAGE_GLOBALS so that the most obvious error (global available, but not in
> the container struct - or the other way around) can be warned about?

Without VIMAGE_GLOBALS is the default; we have been building this for
a few days already. The flip had been so smoothly that almost noone
had really noticed. Marko has done a really great job!

Thus my HEADS UP now after I am confident enough that (almost) all places
were caught and clean.

In case you want to check yourself you can simply put a file into one
or multiple archs conf dir that looks like:

> cat sys/amd64/conf/LINT-VIMAGE_GLOBALS 
include         LINT
ident           LINT-VIMAGE_GLOBALS

options         VIMAGE_GLOBALS

I am doing that build every other day from now to catch the possible
error of a virtualized variable in the container struct w/o the
global. But as this is the least problematic case I do not want to
commit the kernel configuration as it'll make builds longer for everyone,

The more problematic cases that builds cannot catch are:
- static initialization of a virtualized 'global'.
- a newly added virtualized 'global' that is not under #ifdef VIMAGE_GLOBALS

I have scripts to identify the latter already.

The former will only be caught be either code inspection or
"unexpected results" when running.


Bjoern A. Zeeb                      The greatest risk is not taking one.

More information about the freebsd-current mailing list