[Kos-dev] Syscall (pour julien) plus histoire du double fault

Julien Munier kos-dev@yoda.isnpro.com
Wed, 21 Feb 2001 23:14:49 +0100


Salut,

  >Contrairement a ce que nous pensions avec julien, le syscall ne
  >retournera pas l'adresse de la fonction a appeler au CPL3. C'est
  >directement le syscall qui fera cet appel. En effet, toutes les
  >operations d'entrees sorties seront interdites pour le CPL3 (sauf cas
  >particuliers genre serveur X), et donc les drivers devront operer en
  >CPL0. Babel recevra donc un appel du CPL3 via un syscall pour faire tel
  >ou tel truc, et Babel appelera directement la chose en question.

euh, desole thomas, j'avais mal du me faire comprendre, mais j'ai
jamais dit que babel renverrai un pointeur vers la fonction
personnellement j'avais cru justement comprendre que tu m'expliquais
que ca marchait comme ca et en effet j'aimerais passer comme argument
dans a mon syscall

 %eax : le numero du syscall
 %ebx : un pointeur vers une structure 
      struct {
	     struct instance_s *babel;
	     struct instance_s *instance;
	     unsigned long method_number;
	     }
 %ecx : un pointer vers une structure de
        donnee contenant la structure de donnee 
	reclamee par la methode appellee.	    
	     
  >Bien sur cet appel peut etre distinct de Babel, si on veut que Babel
  >reste un strict gestionnaire de ressources.

effectivement ca reste a etudier mais normallement la fonction
babel::_lookup_method et faites pour ca.


par contre, une question interessante conserne les ipcs, on peut
imaginer qu'il y ait plusieurs syscall disponible, dont un specifique
pour les requetes de services a babel et d'autres pour d'autres choses
...  je sais pas comment fonctionneront les ipcs mais on peut imaginer
que ce soit un autre syscall qui s'en charge ? maintenant je n'ai
aucune idee si les ipcs peuvent etre consideree comme une interface
?!?

Julien