<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content="MSHTML 5.00.2014.210" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face="Courier New" size=2>
<P>Je pensais que SOS s'etait eteint d'une mort discrete. J'ai ete surpris
-agreablement- de constater , courant Octobre, qu'il etait toujours vivant.</P>
<P>J'en profite pour rapporter deux classes d'incident que j'ai essentiellement
rencontrees au cours d'exploration de versions derivees de la 9_5. A l'analyse
du code de la version 10, je constate que la plupart des incidents sont encore
applicables.</P>
<P>Il me semble donc utile de les communiquer:</P>
<P>Anomalie constatee:</P>
<P>A. Initialisation incorrecte de variables statiques:</P>
<P>====================================================</P>
<P>Dans "certaines conditions" , certaines variables supposees initialisees ne
le sont pas.</P>
<P>Exemple: </P>
<P>- fs.c: fs_list</P>
<P>- uaccess.c : __uaccess_zero_fool_gcc</P>
<P>- mm_context.c: current_mm_context et list_mm_context</P>
<P>- process.c: process_list (non applicable a la version 10)</P>
<P> </P>
<P>De plus, et inversement, certaines variables , dont l'etat doit etre tres
precis au demarrage et ne faisant l'objet d'aucune action d'initialisation (que
ce soit dans la declaration ou dans une procedure explicite) se retrouvent dans
un etat compatible avec celui attendu et ne perturbent en rien le fonctionnement
de SOS.</P>
<P>Dans "certaines conditions", ce fait est dramatique.</P>
<P>Par exemple:</P>
<P>- fs_virtfs.c: structure virtfs_type</P>
<P>- chardev.c : registered_chardev_classes</P>
<P>- blkdev.c : registered_blockdev_instances</P>
<P>Pour ces trois exemples, ces variables doivent imperativement etre
initialisee a zero. Ceci n'est pas fait, et , dans la plupart des cas, le
systeme fonctionne correctement.</P>
<P> </P>
<P>Le linkeur place toutes ces variables apres la borne __e_load. Cette borne
est definie de maniere a englober les sections ".data" et ".rodata". </P>
<P>Nos variables fautives ne sont donc pas placees dans aucune de ces deux
sections. </P>
<P>Elles echappent ainsi a l'initialisation realisee par le processus de
chargement du noyau (qui arrete le chargement a la borne __e_load).</P>
<P>l'outil "nm" renseigne que ces variables sont placees dans une section 'b'(ou
'B'), c'est a dire , non initialisee. Pour les variables ne faisant pas l'objet
d'une initialisation a la declaration, ce placement ne semble pas aberrant. </P>
<P> </P>
<P>En examinant de pres le comportement de gcc, on constate qu'il traite de
maniere particuliere le placement des variables initialisees a zero: toutes les
variables ainsi initialisee sont placees dans une section placee au dela de
notre borne de chargement. En fait, dans une section ".bss". On peut alors
conjecturer que GCC compte sur le runtime pour initialiser la zone .bss a zero.
Nous en avons un exemple au sein meme de SOS: dans la section "userland", la
fonction de demarrage des taches (_start) commence en tout premier a fixer a
zero toute la zone bss. </P>
<P>Ce dysfonctionnement a ete constate sur un seul PC (sur les 3 uniques PCs qui
m'ont servi de test) et sur une version derivee de la 9.5.</P>
<P>Je pense donc que ,pour une raison que j'ignore (etat initial a zero,
initialisation explicite par le Bios ?), la memoire se trouve souvent dans un
etat compatible avec les attentes de SOS. Ceci n'est pas une raison pour
proposer une version de SOS plus robuste capable de resister a ce type d'alea en
corrigeant ce defaut dans l'initialisation.</P>
<P>De mon coté, j'ai ajoute des instructions explicites d'initialisation dans
les fonctions d'initialisation de chaque module, quand ceci etait possible:</P>
<P>Voir details dans l'annexe.</P>
<P>B. Defaut d'initialisation d'une structure allouee dynamiquement</P>
<P>================================================================</P>
<P>Dans le fichier sos/blkcache.c et dans le cadre de la fonction
sos_blkcache_new_cache , les 3 pointeurs de liste de la structure
sos_block_cache ne sont pas initialises.</P>
<P>Correction suggeree:</P>
<P>...</P>
<P>blkcache</P>
<P>= (struct sos_block_cache*) sos_kmalloc(sizeof(struct sos_block_cache),
0);</P>
<P>if (NULL == blkcache)</P>
<P>return NULL;</P>
<P>--> 3 lignes ajoutees: </P>
<P>list_init(blkcache->free_list);</P>
<P>list_init(blkcache->sync_list);</P>
<P>list_init(blkcache->dirty_list);</P>
<P>... </P>
<P>C. Guerineau </P>
<P> </P>
<P> </P>
<P> </P>
<P> </P>
<P>Annexe:</P>
<P>=======</P>
<P>Code introduit en contournement des problemes d'initailisation de variables
statiques:</P>
<P>- blkdev.c</P>
<P>sos_blockdev_subsystem_setup()</P>
<P>list_init(registered_blockdev_instances)</P>
<P>- fs_virtfs.c</P>
<P>sos_ret_t sos_fs_virtfs_subsystem_setup()</P>
<P>struct sos_fs_manager_type *type = &virtfs_type;</P>
<P>memset(type,0, sizeof(*type));</P>
<P>- process.c (pour version 9_5 maxi)</P>
<P>sos_ret_t sos_process_subsystem_setup()</P>
<P>list_init(process_list);</P>
<P>Quand la fonction d'initialisation n'etait pas disponible ou que
l'initialisation devait se faire tres tot, des fonctions de "presetup" ont ete
utilisees. Elles doivent etre declenchees tres tot dans main.c:</P>
<P>Par exemple:</P>
<P>- fs.c: </P>
<P>void fs_presetup()</P>
<P>{</P>
<P>list_init(fs_list);</P>
<P>}</P>
<P>- mm_context.c</P>
<P>void sos_mm_context_subsystem_pre_setup()</P>
<P>{</P>
<P>list_init(list_mm_context);</P>
<P>current_mm_context = NULL;</P>
<P>}</P></FONT><FONT face="Courier New" size=2>
<P>Remarque:</P>
<P>Cette variable -list_mm_context- fait l'objet d'une initialisation via la
</P>
<P>fonction idoine sos_mm_context_subsystem_setup(). Cependant, cette
initialisation</P>
<P>arrive trop tard car , et comme le souligne son auteur, cette variable est
utilisee</P>
<P>via des appels de fonction sos_paging_map declenchés AVANT cette
initialisation. </P></FONT><FONT face="Courier New" size=2>
<P>- uaccess.c</P>
<P>void uaccess_setup(void)</P>
<P>{</P>
<P>__uaccess_zero_fool_gcc = 0;</P>
<P>}</P>
<P>- chardev.c:</P>
<P>void chardev_setup()</P>
<P>{</P>
<P>list_init(registered_chardev_classes);</P>
<P>}</P>
<P> </P></FONT></DIV></BODY></HTML>