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

[Bjoern A. Zeeb]

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,
etc.

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.


/bz

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