Date: Fri, 15 Aug 2008 18:17:33 GMT From: Julian Elischer <julian@FreeBSD.org> To: Perforce Change Reviews <perforce@freebsd.org> Subject: PERFORCE change 147478 for review Message-ID: <200808151817.m7FIHXfm031070@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=147478 Change 147478 by julian@julian_trafmon1 on 2008/08/15 18:17:22 Fix nits Affected files ... .. //depot/projects/vimage/porting_to_vimage.txt#7 edit Differences ... ==== //depot/projects/vimage/porting_to_vimage.txt#7 (text+ko) ==== @@ -13,13 +13,13 @@ of selected global state variables with constructs that allow for the virtualized state to be stored and resolved in appropriate instances of module-specific container structures. The code operating on virtualized state -has to conform to a set of rules described further bellow, among other things +has to conform to a set of rules described further below, among other things in order to allow for all the changes to be conditionally compilable, i.e. permitting the virtualized code to fall back to operation on global state. The most visible change throughout the existing code is typically replacement -of direct references to global variables with macros; foo_var thus becomes -V_foo_var. V_foo_bar macros will resolve back to foo_bar global in default +of direct references to global variables with macros; foo_bar thus becomes +V_foo_bar. V_foo_bar macros will resolve back to foo_bar global in default kernel builds, and alternatively to some_base_pointer->_foo_bar for "options VIMAGE" kernel configs. Prepending of "V_" prefixes to variable references helps in visual discrimination between global and virtualized state. The @@ -102,7 +102,7 @@ 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 + processors to it, but keep the same filesystem and network setup, or alternatively to share processors but to have virtualised networking. 3/ If the module is to be virtualised, decide which attributes of the @@ -116,7 +116,7 @@ on a virtual system by virtual system basis. 4/ Work out what global variables and structures are to be virtualised to - achieve the behaviour required for part #2. + achieve the behaviour required for part #3. 5/ Work out for all the code paths through the module, how the path entering the module can divine which virtual environment it is on. @@ -124,10 +124,11 @@ Some examples: * Since interfaces are all assigned to one vnet or another, an incoming packet has a pointer to the receive interface, which in turn has a - pointer back to the vnet. + pointer back to the vnet. Often "curvnet" will already have been set + by the time your code is called anyhow. * Similarly, on any request from outside the kernel, (direct or indirect) the current thread has a way to get to the current virtual environment - instance via td->ucred->vimage. For existig sockets the vnet context + instance via td->ucred->vimage. For existing sockets the vnet context must be used via so->so_vnet since td->ucred->vimage might change after socket creation. * Timer initiated actions usually have a (void *) argument which points to @@ -148,7 +149,7 @@ Details: temp. note: for module FOO add a definition for VNET_MOD_FOO in sys/vimage.h. -Thos will eventually be dynamically assigned. +This will eventually be dynamically assigned. For now these instructions refer mainly to VNET and not VCPU, VPROCG etc. @@ -157,8 +158,10 @@ .h file for just this purpose. If a module will never export virtualise symbols beyond it's borders, then this structure may well just be in a common include file for that module. As an example, common networking -(but not protocol) variables have been moved to a file called net/vnet.h , -the gre module has simply added the virtualisation structure to if_gre.h. +(but not protocol) variables have been moved to a file called net/vnet.h, but +the gre module has simply added the virtualisation structure to if_gre.h as +no code outside the gre interface will access those values. + Accesses to virtualised symbols are achieved via macros, which generally are of the same name as the original symbol but with a "V_" prepended, thus the head of the interface list, called 'ifnet' is replaced whereever @@ -173,15 +176,17 @@ When VIMAGE is compiled in, the macro will evaluate to an access to an element in a structure pointed to by a local varible. For this reason, it is necessary to also add, at the beginning of -these functions another MACRO that will instantiate this local variable +these functions another macro that will instantiate this local variable and point it at the correct place. As an example, prior to using the "V_ifnet" structure in a program block, -we must add the following MACRO at the head of a code block enclosing the +we must add the following macro at the head of a code block enclosing the references to set up module-specific base pointer variable: - INIT_VNET_NET(initial_valu); + + INIT_VNET_NET(initial_value); /* initial value is usually curvnet */ When VIMAGE is not defined, this will evaluate to nothing but when it IS defined, it will evaluate to: + struct vnet_net *vnet_net = (initial_value); The initial value is usually something like "curvnet" which in turn @@ -226,9 +231,9 @@ the first entry here; eventually this should be automatically done by module name. The DEPENDSON field tells us the order that modules should be initialised in a new virtual environment. This may later need -to be changes to a list of text module names for dynamic calculation. -The rest of the fields are self explanatory. -With the exception of the symmap entry. +to be changed to a list of text module names for dynamic calculation. +The rest of the fields are self explanatory, with the exception of the +symmap entry. The symmap allows us to intercept calls by libkvm to the linker when it is looking up symbols and to redirect it dynamically. this allows for example "netstat -r" to find the
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200808151817.m7FIHXfm031070>