vimage steps forward.

Julian Elischer julian at elischer.org
Thu May 29 17:53:26 UTC 2008


I hope to spend a couple of days looking at breaking up the current 
patch...


## part 1: all the macros..  the macros will be defined in CURRENT 
FILES I think rather than adding new files.
    POSSIBLY NOT FOR ALL THE MODULES DONE IN THE CURRENT PATCH.

use MD5 to confirm that there are no  editing errors.

## part 2: add the structures and initialisers.


By this time a document should be available describing how to 
virtualise modules. Marko, if you can write a few pages on this,
send it to me and I'll add to it and clean it a bit and send it to
you.. I'll then send it back to you.. we can iterate, and I
would suggest that we make it generally available somewhere so
that others can comment and add as they learn.


## part 3:redefine the macros to be able to switch to using the 
structures or not.

do some performance tests with
   a) global variables
   b) structified variables
  I and ALC expect that we may need to 'tune' teh structures to
  ensure  that heavily used items that are accessed by different CPUS
  are not in the same cache lines.. i.e. either separated by rarely
  used items or by padding and that items used together are clustered.
  This may take some time to test but we can probably get a lot of
  parallelism by getting many people to do the tests as it will
  be relatively easy to do.

## part 4: remove the non-structured versions of the globals and
  adjust the macros so that "non" vimage versions use static copies of
  the structures.

## part 5: add framework for vimage creation etc.

    test

## part 6: start adding more modules, one at a time.


comments:
The structures should be changed from the current form to have a 
header in them that is always the same.. As per the discussions
that header should contain a version number and a reference counter,
(and possibly a magic number).
By  defining this header somewhere we can add debug assist stuff to it 
as needed..

possibly it should also contain some methods and the name of the 
module (for example)..

i.e. a method pointer to a function that can tell if the module is in 
use.. possibly combinign this structure with other per-module 
structures could be considered.





More information about the freebsd-virtualization mailing list