[Kos-dev] Quelques explications

[Thomas Petazzoni]

Bonjour, bonjour,

Et bien comme tous les ans a la même époque, nous nous sommes réunis
avec thomas (d2 n'ayant cette année malheureusement pas pu venir), pour
partager 3 jours de développement.

Conformément a la sage volonté de thomas, nous avons cherche a
continuer le développement le plus loin possible en direction du mode
utilisateur pour cerner un maximum de problèmes et disposer d'une vision
_globale_ des questions.

Bien, trêve de bavardage, voici un petit compte rendu de ces fameuses
*avancées* :

- Remise en route de la création de thread utilisateur : création du
contexte et scheduling.
- Remise en route du syscall et connexion avec le système KARM (qui veut
dire Kos Advanced Resource Management).
- Simplification de l'interface mapping par factorisation de la gestion
du pagefault dans as_page_fault()/_vmm_as.c
- Gestion plus complète du pgfault, région anonyme, COW et extension
dynamique de pile utilisateur.
- Implémentation, Création de l'interface process, permettant aux
applications utilisateurs d'accéder aux grandes fonctions de base :
fork(), exec(), getpid(), getppid(), open(), close() et brk() (sisi tout
ça !)

- Implémentation du fork() et de toutes les fonctions utiles à sa
réalisation (copie d'un espace d'adressage : as_copy(), copie du tableau
des ures : ures_array_copy(), copie du thread thread_copy()). La
fonction ures_array_copy() a nécessité d'ajouter dans la structure view,
une primitives ures_copy() pour copier les données privées de l'ures.
- Implémentation du exec(), vidage de l'espace d'adressage : as_empty(),
fermeture des ures inutiles (4 à n (< MAX_RD_PER_TEAM)). Chargeur ELF
qui crée les régions nécessaire.
- Implémentation de brk(), pour le moment juste création du tas. Il est
pour le moment impossible de l'agrandir ou le réduire (grow/shrink).
Amélioration nécessaire de as_map_ures pour pouvoir créer une région à
une adresse donnée MAP_FIXED fonctionne si pas de région existante à
l'adresse donnée.
- Codage d'un programme de test dans kos-sys avec trois petites
fonctionnettes qui sont néanmoins capable de forker, exécuter un autre
programme qui lui aussi se fork() et tout cela agrémenté de
getpid/getppid et de open/read/write.


Question, Problèmes, Limitations et autres remarques :
- Urgent de revoir la façon dont les .h sont générés à partir des .xml,
la plupart du temps ils ne sont pas générés. Revoir aussi le système de
dépendance : génération de 20x les dépendances avant de compiler.
- On ne forker/execer qu'une team n'ayant qu'un seul thread. En effet,
en dehors du thread, on ne sait comment interpréter l'état des autres
thread, notamment si ils sont en attente sur quelque chose. (Rem. BeOS
possède la même limitation)
- Pour brk(), étudier le fonctionnement de malloc(). Il semble (test
sous linux x86) que si le tas ne peut être agrandi, malloc (dans glibc)
fait sa sauce avec un mmap. Par ailleurs en fonction de la taille a
brkifier, malloc (glibc) préfère parfois le mmap de pages anonymes. Par
ailleurs sous Linux, il semble que certains éléments (les premiers) sont
alloués dans la région des données du programme.
- On a regardé la uClibc, et en fait, elle n'est pas faite pour être
portable sur un autre système que Linux (apparemment). La glibc semble
donc être mieux conçue, mais aussi plus complexe.


voilà pour le résumé, nous attendons vos commentaires,

Bonne soirée,

Thomas & Julien
-- 
PETAZZONI Thomas - thomas.petazzoni at enix.org 
http://www.enix.org/~thomas/ - 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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://localhost/pipermail/kos-dev/attachments/20031027/b6478efe/attachment.bin