Changes between Initial Version and Version 1 of DsxvmMappingInfoStructure


Ignore:
Timestamp:
Aug 29, 2012, 2:58:00 PM (12 years ago)
Author:
meunier
Comment:

Initial version

Legend:

Unmodified
Added
Removed
Modified
  • DsxvmMappingInfoStructure

    v1 v1  
     1
     2[[Mapping Info Structure]]
     3
     4Dsx-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
     6TODO: hypothesis: clustered_architecture, etc.
     7
     8= Document XML Structure =
     9
     10In order to simplify the document type definition, all element attributes are mandatory.
     11
     12
     13== The mapping_info element ==
     14
     15The 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
     21The `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
     29This element contains no attribute, and contains the following elements:
     30 * 1 to ''n'' `cluster` element(s)
     31
     32
     33== The cluster element ==
     34
     35This 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
     38The 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
     46This 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
     55This 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
     58The proc element contains the following element:
     59 * 1 `irq` element
     60
     61
     62== The irq (interrupt request) element
     63
     64This 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
     73This 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
     81This 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
     88This 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
     100The vseg element contains the following elements:
     101 * 1 to ''n'' `vobj` element(s)
     102
     103
     104== The vobj (virtual object) element ==
     105
     106This 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
     116The 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
     122This element contains the following attributes:
     123 * `name`: name of the virtual space set (utilisé ?)
     124 * `startname`: ??
     125
     126The 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
     133This 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