On Sat, 13 Dec 2008, Bjoern A. Zeeb wrote:


Author: bz
Date: Sat Dec 13 19:13:03 2008
New Revision: 186048
URL: http://svn.freebsd.org/changeset/base/186048

 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

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")

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:
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

In case of questions or suggestions ideally follow-up
on freebsd-virtualization@ .


Bjoern A. Zeeb                      The greatest risk is not taking one.
freebsd-virtualization@freebsd.org mailing list
To unsubscribe, send any mail to 

Reply via email to