Re: HEADS UP: vimage - virtualized global variables in the network stack
From: Max Laier Subject: Re: HEADS UP: vimage - virtualized global variables in the network stack Date: Sat, 13 Dec 2008 20:45:16 +0100 > 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? This actually points out why the 'tinderbox' name is bogus for the universe plus failure: universe builds all the kernels. Tinderbox builds LINT only. Warner ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: HEADS UP: vimage - virtualized global variables in the network stack
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. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: HEADS UP: vimage - virtualized global variables in the network stack
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? -- /"\ Best regards, | mla...@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mla...@efnet / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
HEADS UP: vimage - virtualized global variables in the network stack
On Sat, 13 Dec 2008, Bjoern A. Zeeb wrote:
Hi,
Author: bz
Date: Sat Dec 13 19:13:03 2008
New Revision: 186048
URL: http://svn.freebsd.org/changeset/base/186048
Log:
Second round of putting global variables, which were virtualized
but formerly missed under VIMAGE_GLOBAL.
Put the extern declarations of the virtualized globals
under VIMAGE_GLOBAL as the globals themsevles are already.
This will help by the time when we are going to remove the globals
entirely.
As some of you might have noticed that Marko's last commit for the
first time in the series of vimage commits was an actual functional
change. By default HEAD is no longer using the globals.
With my commit the current set of virtualized variables is assumed to
be "clean". This basically means three things:
1) The former globals and their externs are all under #ifdef VIMAGE_GLOBALS
2) The same variables are present in a 'container struct'
3) The initialization of those is done from 'constructor ("init")
functions'
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.
2) Any new virtualized globals must not be directly initialized.
They have to be initialized from a contructor function (which is
usually there already).
If you are confused about some of the terms etc. follow the links in
the "Some documentation" section on the wiki:
http://wiki.freebsd.org/Image
The "Vimage Coding - beginners guide / FAQ" tries to answer the 101
questions. For the beaf you'll find the link to a document in perforce
with the last question (that you may already know).
We'll try to enhance this as we get questions or the integration goes
on.
In case of questions or suggestions ideally follow-up
on freebsd-virtualization@ .
/bz
--
Bjoern A. Zeeb The greatest risk is not taking one.
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"freebsd-virtualization-unsubscr...@freebsd.org"
