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.