[SOS] Accusé de réception.

[David Decotigny]

Bonjour,

Je pense que le moment est venu de te répondre.


Cyril Dupuit a écrit :
> paging.c :
> 
> Dans la fonction : sos_paging_set_prot_of_interval
> 
> Vous avez écrit :
> {
>     if (! SOS_IS_PAGE_ALIGNED(vaddr)) return -SOS_EINVAL;
>     if (! SOS_IS_PAGE_ALIGNED(size)) return -SOS_EINVAL;
> 
>     for ( ; size >= SOS_PAGE_SIZE ; vaddr += SOS_PAGE_SIZE, size -=
> SOS_PAGE_SIZE)
>         sos_paging_set_prot(vaddr, new_prot);
> }
> 
> Problème : Je ne suis pas d'accord avec le fait qu'un bloc complet
> contienne des adresses mappées. C'est à dire que la fonction
> sos_paging_set_prot() peut retourner SOS_VM_MAP_PROT_NONE. Dans ce cas,
> il ne sert à rien de définir une protection à une page non mappée.

Non, bien sûr. Mais si tu regardes comment fonctionne set_prot(), elle
ne cherche pas a modifier les droits d'acces pour les pages non mappees.
cf test + commentaire "  /* No page mapped at this address ? */ ".

> I8254.h :
> 
> Pour protéger de l'inclusion multiple, vous avez écrit :
> #ifndef _SOS_i8259_H_
> #define _SOS_i8259_H_
> 
> L'entête du fichier i8259.h contient aussi cette définition.

Oups, ça c'est un bug, un vrai. Ca prouve que de temps en temps on fait
des copier-collers pour les choses penibles a ecrire (les en-tetes).
Corrigé pour le prochain article.

> Dans certains fichiers (paging.c), vous vous servez d'une macro
> d'assertion. Ce qui me dérange, c'est que cette assertion contient du
> code. Que se passera-t'il lorsque l'assertion sera retirée par le
> préprocesseur dans une version « Realease » de SOS.

C'est en effet une question pertinente. Reponse : en mode "release", on
redefinirait la macro :

  #define ASSERT_FATAL(expr) expr

Voila. Sur du code mort (genre "SOS_OK == structure->champ;"), le
compilo se debrouillera pour le virer. Sur du code utile (genre "SOS_OK
== fonction_bidule(parametre)"), le compilo generera l'appel a
fonction_bidule(parametre) et, normalement, ne devrait pas generer le
test "SOS_OK ==".

> mm_context.c :
[...]
> Vous allouez un bloc mémoire pointé par mmctxt. Ensuite, vous allouez 1
> page mémoire. En cas de mémoire disponible insuffisante, vous libérez le
> bloc mémoire.

Exact, il manque la liberation de la page allouee. Réparé pour le
prochain article.

> Dans la fonction sos_mm_context_duplicate() :
> 
> Le paramètre d'entré n'est pas vérifié.

Non, parce qu'on estime que le noyau, en interne, n'a pas a passer des
objets incorrects. Si ça se produit, le Nirvana c'est que le noyau le
crie tres haut et tres fort, pas qu'il le passe sous silence.

Dans notre cas, plutot que tester que "model" est different de NULL
(c'est le seul test raisonnable qu'on pourrait faire), le mieux est de
faire lamentablement planter le noyau quand il le dereferencera
(model->vaddr_PD). Comme ça, ça se voit, on a droit a un joli message
avec backtrace et tout. C'est exactement a ca que ca sert de ne pas
mapper les page virtuelle 0. Quand je vois que les gens ralent parce
qu'ils obtiennent des "Segmentation fault", ca ne prouve qu'une chose :
qu'ils n'ont rien compris. Car ce genre de bug est la panacée des bugs,
la Limousine de l'erreur de programmation, la Rolls Royce du poliotage.

Les endroits ou les verifs sont necessaires, c'est quand le noyau doit
gerer des choses qu'il ne maitrise pas, comme les parametres d'appels
systeme par exemple. La d'accord, des tests des arguments sont
OBLIGATOIRES. Ca fait desordre si le noyau plante parce que
l'utilisateur s'est joué de lui.

> Dans la fonction sos_mm_context_unref() :
> 
> Le paramètre d'entré n'est pas vérifié.

idem.

> Dans la fonction sos_mm_context_ref() :
> 
> Le paramètre d'entré n'est pas vérifié.

idem.

Merci pour cette relecture attentive !

Bonne soiree,