[SOS] Discussion

[David Decotigny]

Bonjour tout le monde,

Désolé pour le delai, j'ai plein de bonnes et de mauvaises raisons pour 
me/m'in-justifier.

Cyril Dupuit wrote:
> D2, dans ton dernier mail, tu me proposais t'intégrer le traceur 
> d'événements dans SOS, sous la forme d'un patch. Je ne suis pas contre, 
> loin de là.

Ca c'est formidable ! Apres mon mail un peu "speed" la semaine derniere, 
j'avais craint d'avoir découragé tout le monde.

> Mais j'aimerai avoir une copie de vos conventions afin de ne pas 
> chambouler l'esprit du projet SOS.

Il n'y a pas encore de "coding standards" SOS officiels. Juste des 
habitudes de codage et quelques conventions :
  - noms de variables, fonctions, etc. non differenciés selon leur type
    (p.ex pas de trucs genre dw_toto pour signifier que toto est un
    32bits). C'est pas recommandable pour les gros projets, mais pour les
    petits projets comme SOS ça adhère au principe de la flemme maximale
  - les noms ne sont pas du style Java (void TotoEstBeau()) mais sont
    uniformement en majuscules (macros) ou minuscules (le reste)
    eventuellement separes par des '_' (void toto_est_beau())
  - les noms visibles depuis l'exterieur a un module doivent avoir un
    prefixe sos_ (variables, fonctions) ou SOS_ (macros). Tout le reste
    peut s'ecrire n'importe comment a condition que ce soit du "static"
    (visibilite interne au fichier)
  - eviter les typedef sauf pour certains trucs pratiques : sos_ui32_t et
    cie. En particulier pas de typedef pour les struct
  - accolades de blocs dans les fonctions, de if, etc... en debut de
    ligne, genre
       if (toto == est_beau)
       {
          ...
       }
       else
       ...
  - (en bonus) on essaye d'utiliser les extensions gcc qui permettent de
    preciser les specs (__attribute__ ((noreturn)), __attribute__
    ((format(...))), __label__ toto, init de  structure (struct machin){
    .le_champ=12; .le_reste=145};, ...). Voir les pages infos de gcc. Ce
    n'est qu'un bonus, pas une obligation !

Et si tu nous fais parvenir du code pour SOS, on s'adaptera a ton style 
et/ou on reprendra le code pour qu'il cadre a peu pres avec le reste. 
Faut pas exagerer, le nombre de contributions a SOS est encore modeste 
(0), donc on peut mettre nos sales doigts dessus pour qu'elles soient 
dans l'"esprit" SOS.

> Ensuite, le traceur d'événements que j'ai codé s'intègre dans les appels 
> système du noyau et ne peuvent donc pas prendre la forme d'un patch. 
> Sinon, il faudrait patcher tous les fichiers du noyau, ou presque.
> Je réfléchi en ce moment à une solution permettant d'obtenir le 
> fonctionnement de ptrace que je ne connaissais pas.
> Pour cela, il faut que j'utilise les signaux !

En attendant d'avoir des appels systeme, le tracage peut etre utiliser 
pour tracer les appels de certaines fonctions. Pour info, dans notre 
version de SOS on utilise un mecanisme de tracage tout basique vers 
bochs (port 0xe9), relativement transparent. Ca permet de tracer les 
entrees et sorties de fonctions (imbrications) tres simplement :

------------- dans un .h ------------------
extern void _trc_print_exit(void *s);
#define _TRACE() \
   char * toto __attribute(( cleanup(_trc_print_exit) )) = 
__PRETTY_FUNCTION__;\
   sos_bochs_printf("<ENTER(%s)>\n",  __PRETTY_FUNCTION__)
-------------------------------------------

------------- dans un .c ------------------
void _trc_print_exit(void *s)
{ sos_bochs_printf("</EXIT(%s)>\n", *(char**)s); }
-------------------------------------------

Modif de n'importe quelle fonction a tracer :
   int the_function(int toto)
   {
      int est_beau = toto;
      TRACE(); // <----------- Permet de tracer le debut+la fin de la fct

      if (toto == 42)
        return est_beau * toto;
      est_beau ++;
      return toto + est_beau;
   }


Le __attribute(( cleanup(...) )) n'est peut-etre pas valable pour toutes 
les versions de gcc.

> Je suis en train d'étudier le principe de fonctionnement des signaux 
> afin de les intégrer dans mon noyau. Mais, les signaux peuvent être 
> remplacés par d'autres choses :
> - des appels système (SIGCONT, SIGSTOP).
> - des files de messages (gestion du clavier). Etc...

J'aurais du m'abstenir de parler de ptrace. Ca viendra plus tard, si ça 
vient. C'est un peu l'artillerie lourde, mais elegante, pour tracer ce 
qui se passe au niveau de dialogue OS/user. Il n'y a pas besoin de ca 
pour tracer le dialogue. On peut se contenter par exemple de tracer les 
appels systeme dans la routine de traitement des appels systeme.

Comme il n'y a pas encore de syscalls (parce qu'il n'y a pas encore de 
notion d'espace "utilisateur"), on peut se contenter pour l'instant de 
tracer les entrees/sorties de certaines fonctions.

> Pourriez-vous me donner des arguments en faveur des signaux, parce que 
> pour l'instant, je n'en vois pas l'intérêt ?

Oublie pour l'instant.

> Cyril, un développeur qui vous veut du bien.

-- 
d2, voyagiste