[Kos-dev] double fault fonctionnel !

[Thomas Petazzoni]

> Ah je me disais quand même ! :))))))))))

bin voui... hey quand meme on est pas des blaireaux !

> Bon c'est une bonne chose de validée. Reste qu'il y a un cas à tester avant
> de se lancer dans les piles dynamiques et autre : que se passe-t-il si c'est
> un IRQ qui provoque le #DF ? là il s'agit d'une interruption externe,
> autrement dit, ce n'est pas le code interrompu qui est fautif du #DF. Or
> l'EIP dans le TSS system doivent être celui du code interrompu et non celui
> du handler. Je présens que cet IRQ va être perdu et jamais exécuté, ce qui
> est un gros problème à mon avis si on ne peut pas le détecter.

ouais oula c'est complique tout ca.... tres complique.

> 0: mov    $DEADBEEF,%esp // attention boucle infini, il ne faut pas que le
> handler #DF alloue dynamiquement la pile !!!
>     hlt
>     jmp 0b


d'accord je vois.

> le timer 0 devrait afficher une autre barre tournante d'une autre couleur à
> chacune de ses exécutions.
> Comme vous pouvez noter, on crée intentionnellement une pile invalide avec
> la signature 0xDEADBEEF juste avant l'exécution de l'instruction "hlt" qui
> devrait attendre jusqu'à ce qu'un signal d'interruption ait lieu (en
> particulier celui du timer 0). Un #DF apparaîtra forcément qui donnera
> provisoirement sa pile pour laisser continuer l'exécution.

ton test est tellement complique qu'on risque avant de se retrouver avec
la vraie reponse de 50000 bugs... c'est grave chiant.
le hic c'est qu'on a pas trop le choix en fait. c un peu emmerdant
grave. enfin bon je vais essayer, voir ce que ca donne.

> Pour être honnête, je crois que le 2°) est le plus probable.

attends tu vas me faire coder un truc qui a de fortes chances de ne pas
marcher... hum hum... douteux comme machin. le pb c'est qu'on ne sait
pas ce qu'on doit obtenir : avec le double fault, on voulait que ca
revienne dans le thread, mais la on sait pas si on a pas la barre
tournante si c vraiment a cause du DF ou si c'est pour une autre
raison...

> Si on veut vraiment pouvoir exécuter l'IRQ, il faut arriver à déterminer
> quel IRQ a eu lieu. Pour cela il nous faudrait consulter le masque des IRQ
> en état d'attente (pending IRQ) et repérer l'IRQ dans le bitmap obtenu. On
> simule alors un appel d'interruption à cet IRQ depuis le #DF.

c'est a dire, pourrais-tu etre plus explicite ?

amicalement,

thomas
-- 
PETAZZONI Thomas
thomas.petazzoni@meridon.com     UIN : 34937744
Projet KOS : http://kos.enix.org
Page Perso : http://www.enix.org/~thomas/