PERFORCE change 145189 for review

[Julian Elischer]

http://perforce.freebsd.org/chv.cgi?CH=145189

Change 145189 by julian at julian_trafmon1 on 2008/07/14 05:07:45

	Slight cleanups after talking with Marko.

Affected files ...

.. //depot/projects/vimage/porting_to_vimage.txt#4 edit

Differences ...

==== //depot/projects/vimage/porting_to_vimage.txt#4 (text+ko) ====

@@ -14,25 +14,42 @@
    This generally requires NO changes to the network drivers of the classes
    covered (e.g. ethernet).
 
-2/ If the module is to be virtualised, decide which attributes of the 
-   module shoudl be virtualised. 
+2/ decide if your module is part of one of the major module groups.
+   These are V_GLOBAL V_NET V_PROCG V_CPU.
+
+   The reader will note that the descriptions below  use the acronym VNET
+   a lot.  The vimage system has been at this time broken into a number of 
+   subsections. One of these is the "VNET" group. The idea of these
+   subsections is that they might be individually selected as
+   virtualizable in a particular virtual machine instance.
+
+   As an example, in a virtualization, one might to allocate a couple of
+   processors to it, but keep the saem filesystem and network setup, or
+   alternatively to share processors but to have virtualised networking.
+
+   The current code has a "vnet" pointer in the thread. It could be argued
+   that it should actually be a vimage.
+
+   [comments from Marko here]
+
+3/ If the module is to be virtualised, decide which attributes of the 
+   module should be virtualised. 
 
-   For example, It may make sense that ther ebe a single central pool
+   For example, It may make sense that there be a single central pool
    of "struct foo" and a single uma zone for them to come from, with a single
-   lock guarding it. it might also make sense if the "foo_debug" sysctl
+   lock guarding it. It might also make sense if the "foo_debug" sysctl
    controls all the instances at once, while on the other hand, the
    "foo_mode" sysctl might make better sense if it were controllable 
     on a virtual system by virtual system basis.
 
-3/ Work out what global variables and structures are to be virtualised to 
+4/ Work out what global variables and structures are to be virtualised to 
    achieve the behaviour required for part #2.
 
-   
-4/ Work out for all the code paths through the module, how the path entering
+5/ Work out for all the code paths through the module, how the path entering
    the module can divine which virtual machine it is on.
 
    Some examples:
-   * Since interfaces are all assighed to one virtual machine or
+   * Since interfaces are all assigned to one virtual machine or
      another, an incoming packet has a pointer to the receive interface,
      which in turn has a pointer to the virtual machine instance.
    * Similarly, on any request from outside the kernel, (direct or indirect)
@@ -51,13 +68,12 @@
    required for the module to stash away the virtual machine instance
    somewhere, and make associated changes in the code.
 
-5/ Add the code described below to the files that make up the module
-
+6/ Add the code described below to the files that make up the module
 
-
 Details:
 
 (temp. for module FOO add a definition for VNET_MOD_FOO in sys/vimage.h)
+For now these instructions refer mainly to VNET and not VCPU etc.
 
 Symbols defined in other modules that have been virtualised will have been
 moved to a module-specific virtualisation structure. It will be defined in a