[Kos-dev] Travaux de la semaine derniere

[d2]

Bonjour,

Chose promise, chose due... Voici un resume des changements appoprtes
la semaine derniere, pendant notre reunion Thomas/d2.

 * Karm(Julien, faut que tu nous rappelles ce que ca veut dire), srructure :
   - revu API generale :
     Une kres n'est pas grand chose. Ca pointe vers une liste de
     "views", POINT. Une view est associee a 1 interface particuliere,
     et correspond a :
       - l'implantation de l'interface => ptr vers un tableau de
         methodes
       - la liste des ures de la kres ouvertes selon l'interface
     C'est la methode "lookup" de l'interface Directory qui cree les
     kres et les views associees. Ca ne peut se faire qu'a ce moment
     la. Le lookup selectionne les vues de la kres a creer en
     fonction du type de la kres (block, file, ...).
     C'est tres simple, et facile a utiliser et etendre.
   - les interfaces supportees sont declarees dans
     modules/karm/interface/ et interface.c s'occupe de les repertorier
     toutes. Pour l'instant, tout est defini en dur a la
     compil. Quelques verifs sont faites pour assurer un minimum de
     coherence entre ce qu'il y a dans interface/ et interface.h
   - libblockfile pour ajouter automatiquement la view file a 1 kres
     qui supporte la view block
   - libfilemap : rajoute un view mapping sur une kres qui dispose de
     la view file
   - nscache : prise en compte correcte des . et ..

 * Karm, interfaces, drivers, etc...
   - devfs : mise a jour nouvelle API. Aucune modif profonde
   - fakefs : idem + ajout de 1 repertoire "file", qui sert pour le
     moment uniquement a monter un disque.
   - driver IDE (detecte des CD sous bochs, bizarre) + integration
     dans karm => montage dans devfs (dev/disk) + export de
     l'interface Block + utilisation de libblockfile pour exporter une
     view File.
   - modules/part/ : lecture de la table des partoches PC + montage
     dans devfs (/dev/part). Supportent la view block et la view file
     grace a libblockfile (simplifie considerablement FAT).
   - FAT : support de FAT12/16/32, teste et approuve (noms courts
     uniquement). Suppose qu'on monte le FS sur une ures ouverte avec
     le view file. Montage sur un repertoire de fakefs, en
     l'occurence /file
   - kres devzero (cf modules/vmm) avec view mapping pour faire
     l'equivalent d'un map /dev/zero

 * VMM
   - mapping de kres qui ont une interface file avec
     libfilemap. demand paging Ok
   - revu architecture interne. Plus de notion d'access_range_t. Tout
     est simple region dans un espace d'adressage. Adoption de la
     philosophie "on fait le minimum, on ajoute en cours de route
     suivant le besoin" : toutes les structures reduites au minimum,
     API reduite au minimum, juste pour aller jusqu'a mapper devzero
     et des kres, et tester le plus vite possible. Pas de "cassage" de
     region pour l'instant (mprotect, mmap, ...).

 * src : reorganisation
   - repertoire lib/ avec 1 sous-rep par type de bibliotheque (std
     correspond a une mini libc)
   - team plus clean : plus de mm_context dans team, puisque ca
     concerne la memoire, c'est donc deplace dans address_space.
   - evite quelques typedef sur des struct, ca oblige a mettre struct
     explicitement, c'est plus clair.

 * misc
   - plus de fonction de chaines de caracteres dangereuses (strcpy,
     sprintf, ...). Tout se fait de facon controlee, avec ajout
     garanti du 0 terminal et respect des tailles de chaines =>
     strzcpy, snprintf, ...
   - debug : revu la config du debug ; separation nette 1/ detection
     des methodes supportees, 2/ methodes activees. Fonction dumpmem
     pratique (analogue hexdump).
   - types count_t, size_t, offset_t, large_size_t, large_offset_t
     pour eviter de tout faire avec size_t/offset_t. Seek utilise des
     large_offset (64bits, signe)
   - snprintf utilise un sprintf  a usage interne uniquement (static)
     pour certains types. Trouver un snprintf POTABLE (kvprintf de BSD ?)
   - tty : generation du .c de la kmap a partir d'un fichier .map
   - wolfgang : tout uniforme pour la gestion des commandes du shell
     basique (tableau utilise par commande help), passage d'argument(s),
     "script" sous la forme d'un tableau de chaines contenant les
     commandes a executer a l'init.
   - liblist : la visite est exhaustive, mais ne respecte pas l'ordre
     croissant/decroissant. Pour le moment, on a essaye de trouver une
     machine a ete pour eviter la recusrivite, mais ca marche
     peut-etre pas. A terme, on va utiliser un marquage.

Aucune synchro serieuse pour le moment.

Bonne soiree,

-- 
d2