| 63 | == Plateforme multi-processeur == |
| 64 | |
| 65 | Pour une plateforme multi-processeur, les changements sont les suivants : |
| 66 | * il n'y a toujours qu'un seul composant `IOC`. |
| 67 | * il n'y a également qu'un seul composant pour les autres périphériques (`ICU`, `TIMER`, `DMA` et `TTY`) mais qui présentent chacun plusieurs sous-instances virtuelles. |
| 68 | |
| 69 | Ces instances virtuelles ont leur ensemble de registres adressables par span (en fonction du numéro de processeur) : |
| 70 | * un processeur `P[i]` trouvera l'`ICU` qui lui est attaché avec la formule suivante : `icu_seg_base + proc_id * ICU_SPAN`. |
| 71 | * même comportement pour les autres périphériques. |
| 72 | |
| 73 | Concernant la cartographie des interruptions, l'idée est la suivante : |
| 74 | * l'`IOC` est toujours connecté à irq_in![0]. |
| 75 | * ensuite, on a un ensemble de lignes d'interruptions pour `TIMER`, `DMA`, `TTY*` par processeur. |
| 76 | |
| 77 | Cet ensemble a un span qui suit la formule suivante : `irq_span = 2 + N_TASKS` (2 car `TIMER` et `DMA` ont des lignes fixes, `N_TASKS` car le nombre de lignes d'interruptions pour le `TTY` d'un processeur dépend du nombre de tâches qui s'exécutent dessus). |
| 78 | |
| 79 | Le span global pour un processeur `P[i]` suit la formule : `irq_base_number = 1 + i * irq_span`. |
| 80 | |
| 81 | Enfin, on soulignera la contrainte suivante : il est impossible, avec les 32 lignes d'interruption possibles en entrée de l'`ICU`, de supporter la configuration maximale, à savoir 8 processeurs et 4 tâches par processeur. Le maximum supporté sera par exemple, 6 processeurs et 4 tâches/processeur ou 8 processeurs et 2 tâches/processeur. |
| 82 | |