[Kos-dev] Double fault : ca continue

[d2]

Imaginons qu'on fasse la chose suivante : on se cree un petit segment
custom (1 par pile cpl0 a mettre dans la gdt, ou 1 global mis a jour a
chaque chgt de contexte ; a defnir question perf/extensibilite) qui
correspond a la pile cpl0 en cours moins quelques octets au bas de
cette pile.

Comme ca, c'est une faute et pas un abort qui est levee quand on
arrive pres du bas de la pile, et on peut alors prendre les mesures
appropriees (extension de la pile), avant de revenir au contexte
interrompu. On se limite alors a n'avoir que le handler de #SS qui est
en task gate. Bon, evidemment, faut pas qu'on se choppe une exception
plus prioritaire quand on est en bas de cette pile.

la question qui se pose : qu'est-ce que ca donne niveau faisabilite et
perfs que d'avoir un segment unique dedie a la pile courante, et de
modifier ce segment a chaque context switch : est-ce qu'il faut
refaire un lgdt ? Ou est-ce qu'il suffit de recharger la partie cachee
du ss a chaque context-switch ? Quid des perfs ?

Faudrait tester...

Mais re-insistons : si on se choppe un truc plus prioritaire que #SS
alors qu'on est en bas de pile, ce qui est assez probable puisque #SS
a la plus faible priorite, on se retrouve avec un doublefault tres
vite.

En allocation dynamique de pile cpl0, on va se mettre tres souvent
dans ce cas dangereux. Je pense que ca peut etre genant. En alloc
statique, on arrivera moins souvent en bas de pile, donc on se mettra
moins souvent dans le cas dangereux. Et si on se met dans le cas
dangereux, je pense qu'on peut partir du principe que c'est parce que
il y a recursivite, donc bug de realisation, ou alors que la pile est
trop petite (donc bug, mais de conception).

Bref, finalement, finalement, je pense que ca peut etre interessant
d'essayer, mais ca ne me parait pas forcement une bonne solution
d'adopter ce mecanisme a plus long terme.

-- 
d2