| 1 | |
| 2 | [[Mapping Info Structure]] |
| 3 | |
| 4 | 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. |
| 5 | |
| 6 | TODO: hypothesis: clustered_architecture, etc. |
| 7 | |
| 8 | = Document XML Structure = |
| 9 | |
| 10 | In order to simplify the document type definition, all element attributes are mandatory. |
| 11 | |
| 12 | |
| 13 | == The mapping_info element == |
| 14 | |
| 15 | The mapping file is constituted of a single `mapping_info` element, containing the following attributes: |
| 16 | * `name`: the name of the mapping described |
| 17 | * `signature`: ''what is it?'' (Mohamed?) |
| 18 | * `clusters`: the number of clusters used in the mapping. It must correspond to the number of clusters in the targeted architecture |
| 19 | * `vpsaces`: the number of vspaces defined. This number is typically equal to the number of applications (requirement?) |
| 20 | |
| 21 | The `mapping_info` element contains the following elements: |
| 22 | * a `clusterset` element, describing the targeted hardware |
| 23 | * a `globalset` element, describing the global segments, i.e. segments replicated in all virtual spaces |
| 24 | * a `vspaceset` element, describing the mapping for all virtual spaces |
| 25 | |
| 26 | |
| 27 | == The clusterset (cluster set) element == |
| 28 | |
| 29 | This element contains no attribute, and contains the following elements: |
| 30 | * 1 to ''n'' `cluster` element(s) |
| 31 | |
| 32 | |
| 33 | == The cluster element == |
| 34 | |
| 35 | This element contains the following attribute: |
| 36 | * `index`: the cluster index, or ''id''. It is unique for each cluster and must range from 0 to ''n - 1''. The cluster index make the correspondance with the cluster id in the architecture. |
| 37 | |
| 38 | The cluster element contains the following elements: |
| 39 | * 0 to ''n'' `pseg` element(s) |
| 40 | * 0 to ''n'' `proc` element(s). The number of `proc` elements must be equal to the number of processors in this cluster in the targeted architecture (doit être le même dans chaque cluster ?). |
| 41 | * 0 to ''n'' `periph` element(s) |
| 42 | |
| 43 | |
| 44 | == The pseg (physical segment) element == |
| 45 | |
| 46 | This element contains the following attributes: |
| 47 | * `name`: name of the segment. The name of the segment is not related to any segment name in the architecture. It is used to associate virtual segments on physical segments inside the mapping info file. |
| 48 | * `base`: base of the physical segment |
| 49 | * `type`: type of the segment. It can be one of `RAM`, `ROM`, `PERI` (influence ??) |
| 50 | * `length`: size of the segment (utilisé pour des vérifications ?) |
| 51 | |
| 52 | |
| 53 | == The proc (processor) element == |
| 54 | |
| 55 | This element contains the following attribute: |
| 56 | * `index`: the processor index, or ''id''. It is unique for each processeur and must range from 0 to ''n - 1'' inside the cluster (vrai ? ou id global ?). The index corresponds to the processor id in the architecture |
| 57 | |
| 58 | The proc element contains the following element: |
| 59 | * 1 `irq` element |
| 60 | |
| 61 | |
| 62 | == The irq (interrupt request) element |
| 63 | |
| 64 | This element contains the following attributes: |
| 65 | * `type`: The type of interrupt request. Currently can only be `HARD` (?) |
| 66 | * `icuid`: the identifier of ..? |
| 67 | * `isr`: the interrupt sub-routine...what? |
| 68 | * `channel`: the channel of the... (toujours égal à icuid ?) |
| 69 | |
| 70 | |
| 71 | == The periph (peripheral) element == |
| 72 | |
| 73 | This element contains the following attributes: |
| 74 | * `type`: type of the peripheral. It can be one of `TTY`, `TIM` (timer), ? |
| 75 | * `psegname`: name of the physical segment in which the peripheral is mapped. This name must be one of the pseg elements' name. (pourquoi nom du pseg et pas nom du vseg ?) |
| 76 | * `channels`: the number of channels in the peripheral (one channel usually corresponds to one processor; an exception is for ttys where one channel is used for the operating system) |
| 77 | |
| 78 | |
| 79 | == The globalset (global set) element == |
| 80 | |
| 81 | This element contains no attribute, and contains the following elements: |
| 82 | |
| 83 | * 0 to ''n'' `vseg` element(s) |
| 84 | |
| 85 | |
| 86 | == The vseg (virtual segment) element == |
| 87 | |
| 88 | This element contains the following attributes: |
| 89 | * `name`: name of the virtual segment (utilisé quelque part ?) |
| 90 | * `vbase`: base address of the virtual segment in the final binary. Depending on the virtual segment, it can be chosen arbitrarily or not (détailler) |
| 91 | * `clusterid`: ''pourquoi est-ce que c'est nécessaire ?'' |
| 92 | * `psegname`: name of the physical segment in which this virtual segment must be mapped. This name must be one of the pseg elements' name. |
| 93 | * `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: |
| 94 | * `C`: the segment is cached |
| 95 | * `X`: the segment is executable |
| 96 | * `W`: the segment is writable |
| 97 | * `U`: the segment is accessible is user mode |
| 98 | * `ident`: is 1 if the segment is an identity segment, 0 otherwise. An identity virtual segment is a virtual segment whose base address is the same as the one of the physical segment it is mapped on. ''Pourquoi a-t-on besoin de ça ? de toutes façons toutes les infos sont répliquées...'' |
| 99 | |
| 100 | The vseg element contains the following elements: |
| 101 | * 1 to ''n'' `vobj` element(s) |
| 102 | |
| 103 | |
| 104 | == The vobj (virtual object) element == |
| 105 | |
| 106 | This element contains the following attributes: |
| 107 | * `name`: the name of the virtual object. ''utilisé ?'' |
| 108 | * `type`: type of the virtual object. It can be one of `ELF`, `PERI`, `BUFFER`, `MWMR`, `PTAB` (influence ?) |
| 109 | * `length`: size of the virtual object in bytes. ''utilisé pour quoi ?'' |
| 110 | * `align`: logarithm in base 2 of the alignemnt required for this segment. For example, a value of 13 means that the segment must be aligned on 0x2000 |
| 111 | * `binpath`: path to the file to load in this segment, if any. This path can be relative or absolute. |
| 112 | |
| 113 | |
| 114 | == The vspaceset (virtual space set) element == |
| 115 | |
| 116 | The vspaceset element has no attribute and contains the following elements: |
| 117 | * 0 to ''n'' `vspace` element(s) |
| 118 | |
| 119 | |
| 120 | == The vspace (virtual space) element == |
| 121 | |
| 122 | This element contains the following attributes: |
| 123 | * `name`: name of the virtual space set (utilisé ?) |
| 124 | * `startname`: ?? |
| 125 | |
| 126 | The vspace element contains the following elements: |
| 127 | * 0 to ''n'' `vseg` element(s) |
| 128 | * 0 to ''n'' `task` element(s) |
| 129 | |
| 130 | |
| 131 | == The task element == |
| 132 | |
| 133 | This element contains the following attributes: |
| 134 | * `name`: name of the task. It must be the name of the main function of the task. |
| 135 | * `clusterid`: cluster id in the targeted architecture of the processor on which to execute the task. |
| 136 | * `proclocid`: processor local id on which to execute the task. |
| 137 | * `stackname`: name of the vobj on which to place the task's stack. It must the name of one of the vseg element. |
| 138 | * `usetty`: is 1 if the task has to write its output on a tty, 0 otherwise. |
| 139 | * `startid`: (j'ai oublié ce que c'est) |
| 140 | |
| 141 | |
| 142 | |
| 143 | |