[Kos-dev] Avancée du développement

[Thomas Petazzoni]

Salut,

Aujourd'hui, j'ai terminé de refaire fonctionner KOS avec mes
modifications concernant vmap, rmap et physmem.

Vous trouverez en fichier attaché le patch correspondant.

Au niveau de vmap :

 - Une coupure en 3 étapes des opérations de mapping / unmapping pour
   les besoins de la synchronisation. Première étape pour l'allocation
   éventuelle de structures ou de pages (sans lock), deuxième étape
   pour faire le mapping ou le démapping d'une seule traite (avec
   lock), troisième étape pour libérer d'éventuelles structures ou
   pages inutilisées (sans lock). Pour l'instant, pas de spare_pt
   comme d2 l'avait fait pour éviter d'allouer/libérer à chaque fois
   une page physique pour le PT. Ce n'est pas optimisé.

 - La fonction de synchronisation des PDs (pour l'espace noyau) a été
   déplacée dans _team_mm_context.c, puisque c'est dans cette fonction
   que se déroule l'initialisation du PD table mapper, ainsi que
   l'allocation/libération de slots dans ce PD table
   mapper. Désormais, la fonction de synchronisation des PDs ne
   récupère plus la liste des teams, elle parcourt directement
   l'ensemble du PD table mapper à la recherche de PDs à mettre à
   jour. Oui, c'est peut être moins optimal, mais 1) c'est plus
   propre et 2) il faut voir que cette fonction n'est appelée que lors
   de l'allocation ou de la libération d'un PT pour l'espace noyau
   (pas pour l'espace utilisateur), c'est à dire tous les 4 Mo de
   mémoire allouée.

 - Une réorganisation des rôles entre setup_mm_ctxt et les fonctions
   de mapping/unmapping/etc... D'ailleurs cette répartition des rôles
   pourrait encore changer lors de la modification de vmm.

 - Il y a un comptage d'utilisation des PTs qui fait qu'on peut les
   libérer quand ils deviennent inutilisés.

Au niveau de rmap :

 - Même principe que d2 avec des pointeurs de fonctions, sauf que
   maintenant on en a 4, pour les 4 opérations suivantes : allocation
   d'une struct rmap, libération d'une struct rmap, ajout d'une
   struct rmap dans une page physique, retrait d'une struct rmap d'une
   page physique. Cette arnaque est décrite en haut du fichier, mais
   j'ai pas encore repris les commentaires de d2 de l'ancienne
   implémentation qu'il faudrait que je remette car ils sont utils.

 - Au niveau de l'initialisation des rmap manquants, je n'utilise pas
   la même méthode que d2. Je préfère parcourir les PTs pour
   construire les reverse mappings plutôt que d'aller farfouiller dans
   les chained_range de kmem. C'est peut être un peu plus lent, mais
   c'est de l'initialisation, donc on s'en fout ;-)

Au niveau de pmm :

 - La structure gpfme est maintenant opaque au système, et toutes les
   fonctions ne prennent plus de gpfme * en paramètre, mais plutôt une
   paddr. Ce dernier choix est discutable.

 - Les fonctionnalités d'ajout de pages physiques supplémentaires ont
   été désactivées pour l'instant. Elles ne sont pas primordiales au
   fonctionnement du système. On verra à les réactiver le moment venu.

 - Comptage de référence sur les pages + comptage d'utilisation. Le
   comptage d'utilisation est utilisé uniquement pour compter le
   nombre de pages qui utilisent un PT, mais pourra peut être servir à
   d'autres choses ?

 - Des fonctions dans _pmm_rmap.c pour récupérer la liste des rmap et
   la mettre à jour.

Au niveau de vmm :

 - Mise à jour de _vmm_map.c pour utiliser les nouvelles
   fonctions. Pour l'instant, un gros spinlock de goret nommé
   vmm_spinlock est pris avant l'utilisation des fonctions de
   arch/mm. Tout cela doit être retravaillé.

 - Tous les modules doivent utiliser les fonctions de _vmm_map.c et
   non directement les fonctions de arch/mm. De toute façon, avec le
   mapping/unmapping en 3 temps, ça devient galère de mapper une page,
   alors que map_virtual_page() et unmap_virtual_page() de _vmm_map.c
   font ça toutes seules.

Un peu partout :

 - Des corrections pour que ça marche ;-)

 - Des commentaires doxygen sur _vmap.c, _rmap.c,
   _team_mm_context.c. Oui, moi je mets la documentation des fonctions
   dans le .c, parce que 1) Ca permet de documenter et les fonctions
   externes et les fonctions static, 2) Pour la documentation du .h,
   Doxygen va récupérer la documentation du .c, alors que l'inverse
   n'est pas vrai.

 - Mise en place de macro DEBUG_PRINT1, DEBUG_PRINT2, DEBUG_PRINT3
   avec des niveaux de debuggage. Chaque module définit un DEBUG_LEVEL
   dans son Makefile, compris entre 0 et 3. A 0, il n'y aucun message
   de debug, à 3 y'en a tout plein. Pour l'instant, peu de modules
   utilisent ce nouveau mécanisme, qui n'est pas forcément optimal. Je
   suis pas un pro des macros, il y a peut être moyen de faire
   nettement mieux.

Au niveau de la doc :

 - dans modules/, on tape make doc, et après on va dans
   doc/src-html-doc et doc/src-latex-doc ;)

Questions :

 - Est-ce qu'on peut dire à Doxygen de pas considérer les appels à
   EXPORT_FUNCTION() comme des définitions de fonctions ?

 - Dans quelle mesure serait-il envisageable de changer un peu la
   macro EXPORT_FUNCTION() pour qu'elle prenne un paramètre
   supplémentaire : le module vers lequel on autorise l'export de la
   fonction.

   On pourrait ainsi écrire :
     EXPORT_FUNCTION(arch_do_map_virtual_page, "vmm");
   pour s'assurer que seul vmm peut utiliser cette fonction.

   Et on pourrait continuer à écrire
     EXPORT_FUNCTION(kmalloc, "all") ou mieux EXPORT_FUNCTION(kmalloc)
   pour dire que tout le monde peut l'utiliser.

Commentaires, réactions, suggestions bienvenus !

Bonne soirée,

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni at enix.org 
http://thomas.enix.org - Jabber: kos_tom at sourcecode.de
KOS: http://kos.enix.org/ - Lolut: http://lolut.utbm.info
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kos-vmap-rmap-pmm.patch.gz
Type: application/octet-stream
Size: 52282 bytes
Desc: not available
Url : http://the-doors.enix.org/pipermail/kos-dev/attachments/20041003/39bc2af5/kos-vmap-rmap-pmm.patch-0001.obj