Flat Model, Multi-segment model...

J'essaye depuis le début de créer un OS basé sur un modèle qu'on appelle "Multi-Segment" par rapport au spécificité de l'architecture Intel et de sa fameuse segmentation. J'avais trouvé le concept attirant et surtout je dois avouer que je n'avais vraiment pas envis de plonger mes mains dans la pagination.
Au début je voyais dans la GDT 4 descripteurs de base (NULL, CodeNoyau?, Data Noyau, Stack Noyau).
Ensuite le reste de la GDT sera dédié aux segments utilisateurs.

Par quoi serait caractérisé un processus utilisateur ?

• Un TSS qui aurait son descripteur dans la GDT
• Une LDT contenant 3 descripteurs (Code utilisateur, Data utilisateur, et le Stack pour finir).

Que ferait le noyau de son cote ?
Le noyau possèderait un tableau statique qui contiendrait dans chacune de ses cases une structure caractérisant un processus pour l'OS (PID, état, priorité, TSS, LDT etc...).
A travers l'IRQ0 dont l'entrée dans l'IDT pointera vers une fonction de scheduling, le noyau s'occupera d'elire un processus (mise en place de son TSS, on fait pointer les registres vers ses descripteurs) et de mettre à jour son tableau.

Nous avons donc une limite en terme de nombre de processus qui est égale a peu pret au nombre d'entrée dans la GDT / 2. Car un processus occupe 2 entrées dans la GDT : Une pour son TSS et l'autre pour sa LDT.

Tout semblait bien et cohérent, mais arriva le chapitre sur l'allocation dynamique...
Aie Aie, tout se complique, nous travaillons donc avec des segments !

Un segment possède une taille fixe et décrit donc une zone précise de la mémoire.
Lorsque je crée un processus je lui donne un emplacement en mémoire contigue, de la taille dont ont besoins ses données et son code.
Si ce processus souhaite allouer de la mémoire, plusieurs choses :

• On pourrait agrandir la limite du descripteur de segment : problème on peut écraser des données qui suivent la mémoire décrite par ce descripteur, mémoire qui peut appartenir à un autre processus : donc impossible a priori comme solution.
• On pourrait créer un nouveau descripteur de segment dans la LDT du processus dont la limite serait la taille de la mémoire que l'on souhaite allouer et qui décrirait donc un emplacement libre de cette taille en mémoire vive.

Problème : nous avons donc un nouveau segment de données.
Comment faire pour que le processus puisse utiliser ce segment ? Cela implique un changement du registre DS, enfin cette solution me semblait irréalisable, je ne saurai meme pas comment la gérer, mais me semblait la plus propre.

• Solution trés crade et absolument pas performante : On recherche un emplacement mémoire contigu et assez grand pour contenir le processus + la taille de la mémoire qu'il souhaite allouer, de ce fait on aurait tout dans le meme segment. C'est une solution absurde mais c'est la seule qui me semblait fonctionelle !

Comme me le faisait remarqué David Decotigny (SOS) la solution la plus propre est bien sur la deuxième mais avec gcc ce n'était pas evident : il repose tres tres peu sur un modele multi-segments et ne gere pas tout seul le passage d'un segment a l'autre : il faut l'aider.

En fait nous nous sommes trés vite rendus compte que le problème venait des outils et non du modèle : La plus part des compilateurs actuels sont basés sur un Flat modèle et non une multi segmentation.

J'ai donc décidé d'utiliser la pagination moi qui ne voulait surtout pas l'utiliser... Bien sur je pourrais m'en passer, mais je vois mal un OS incapable d'allouer dynamiquement de la mémoire.

La pagination permet donc a un processus de lui faire croire qu'il possède un espace contigue et linéaire alors qu'en fait toutes la mémoire dont il dispose n'est que trés rarement physiquement contigue. C'est toute la puissance de la pagination : Associé à une adresse physique : une adresse virtuelle !