Changes between Version 8 and Version 9 of DsxvmMappingInfoStructure

Timestamp:

Sep 5, 2012, 11:53:43 AM (12 years ago)

Author:

meunier

Comment:

(mineure) Corrections remarques Clément

DsxvmMappingInfoStructure

@@ -5 +5 @@
 
 
-Dsx-vm needs to have a way to communicate with the operating system to specify how to map code, data and taks on the architecture. To this end, an xml data structure has been defined, and is presented below. This xml file is produced by Dsx-vm and read by the operating system and used in particular for page tables generation and thread mapping on processors.
+Dsx-vm needs to have a way to communicate with the operating system to specify how to map code, data and tasks on the architecture. To this end, an xml data structure has been defined, and is presented below. This xml file is produced by Dsx-vm and read by the operating system and used in particular for page tables generation and thread mapping on processors.
 
 TODO: hypothesis: clustered architecture, etc.
@@ -59 +59 @@
 
 This element contains the following attribute:
- * `index`: the processor index, or ''id''. It is unique for each processor and must range from 0 to ''n - 1'' inside the cluster. The index corresponds to the processor id in the architecture.
+ * `index`: the processor index, or ''id''. It is unique for each processor and must range from 0 to ''n - 1'' inside the cluster (with ''n'' being the number of processor). The index corresponds to the processor id in the architecture.
 
 The proc element contains the following element(s):
@@ -72 +72 @@
  * `channel`: the peripheral channel from which the interruption is connected (for peripherals with only one channel, it must be set to zero).
  * `isr`: the interrupt sub-routine types:
-    * `ISR_SWITCH`: Used to schedule the tasks of a processor (triggers a context-switch); the channel attribute must be equal to the processor id.
+    * `ISR_SWITCH`: Used to schedule the tasks of a processor (triggers a context-switch). The channel attribute must be equal to the processor id.
     * `ISR_TTY`: handles the interruptions emaning from the tty
     * `ISR_DMA`: handles the dma interruptions
@@ -90 +90 @@
    * `NIC`: nic buffer peripheral
    * `IOB`: io bridge peripheral
- * `psegname`: name of the physical segment of the peripheral. This name must be one of the pseg elements name, and whose type is `PERI`. This is used to make the association between the physical segment declared in the architecture and the peripheral (pourquoi nom du pseg et pas nom du vseg ?)
+ * `psegname`: name of the physical segment of the peripheral. This name must be one of the pseg elements name, and whose type is `PERI`. This is used to make the association between the physical segment declared in the architecture and the peripheral
  * `channels`: the number of channels in the peripheral (one channel usually corresponds to one processor)
 
@@ -104 +104 @@
 
 This element contains the following attributes:
- * `name`: name of the virtual segment. This name is used only for clarityand has no functional use.
+ * `name`: name of the virtual segment. This name is used only for clarity and has no functional use.
  * `vbase`: base address of the virtual segment in the final binary. It must be page size (0x1000 or 4Ko) aligned.
  * `psegname`: name of the physical segment in which this virtual segment will be mapped. This name must be one of the pseg elements name.
- * `clusterid`: cluster id in which the the psegname have been defined.
+ * `clusterid`: cluster id in which the psegname have been defined.
  * `mode`: specific properties of the segment. The value is of the form `[C_][X_][W_][U_]` e.g. `C_W_`. Each character indicates if the property is selected (letter) or not (underscore). The properties are the following:
    * `C`: the segment is cached
@@ -122 +122 @@
 
 This element contains the following attributes:
- * `name`: the name of the virtual object. ''utilisé ?'' pour obtenir les ressources (mwmr, barrier,..) en mode utilisateur grace a l'appel system vobj_get_vbase(stdio.c).
+ * `name`: the name of the virtual object. This is used to obtain the virtual base address of the vobj: this name is a parameter of the vobj_get_vbase syscall along with the vspace name. Two vobj elements can't have the same name inside a vspace, even if they are in different vseg elements.
  * `type`: type of the virtual object. It can be one of the following:
    * `ELF`: describes an elf section. The system has to load the elf described by the binpath in this segment.
@@ -134 +134 @@
 
  * `length`: size of the virtual object in bytes. The sum of the length of all vobj defines the length of the vseg.
- * `align`: (optional) logarithm in base 2 of the physical alignemnt required for this segment. For example, a value of 13 means that the segment must be aligned on 0x2000. Be careful when using this attribute, since the size of the vobj will be incremented until the (??)
+ * `align`: (optional) logarithm in base 2 of the physical alignemnt required for this segment. For example, a value of 13 means that the segment must be aligned on 0x2000. Be careful when using this attribute, since the size of the vobj will be incremented until the next aligned address.
  * `binpath`: path to the file to load in this segment, if any. It is used only for ELF and BLOB segments, and must empty for other segment types. This path can be relative or absolute.
 
@@ -152 +152 @@
 The vspace element contains the following element(s):
  * 0 to ''n'' `vseg` element(s)
- * 0 to ''n'' `task` element(s)
+ * 0 to ''n'' `task` element(s) (Remarque : que se passe-t-il si 0 task ? accès impossible ? accès possible de toutes les tâches ? autre ?)
 
 
@@ -164 +164 @@
  * `usetty`: if 1 the task a tty will be reserved for the task, 0 otherwise.
  * `startid`: indicates the index of the function to execute in the task function entry table of the corresponding vspace.
+ * `usefbdma`: (optional) if set (with value 1), indicates that the task uses a frame buffer with dma accesses (`fb_write` function).
 
-