[Kos-dev] Deux visions differentes de Babel

[Thomas Petazzoni]

Bonjour,

Durant ce WE chez David, j'ai pu discuter avec lui de la facon dont
nous voyons Babel. Et il en ressort clairement que nous n'avons pas
tout a fait la meme vision de la place de Babel dans le noyau. Je ne
sais pas quelle est la meilleure solution, c'est pourquoi je vais
exposer ici les deux differentes visions en essayant dans la mesure du
possible d'analyser pour chacune les avantages et les
inconvenients. Ce message est particulierement destine a Julien,
puisque c'est lui qui a ecrit Babel, mais bien =E9videmment et comme
d'habitude tous les commentaires, suggestions et idees sont les
bienvenues.

Les deux visions different clairement par la place de Babel dans le
noyau.=20

Vision 1 :
Pour moi, Babel est au coeur du noyau. Il est utilise a la fois par
l'utilisateur et par le noyau. Le noyau repose sur Babel pour l'acces
aux peripheriques et aux fichiers.

Vision 2 :
Pour David, Babel n'est QUE l'interface entre le noyau et
l'utilisateur. Pour acceder aux peripheriques, le noyau doit maintenir
de son cote des structures de donnees lui permettant de faire ca :
interfaces internes au noyau notamment. Les objets Babel (interface et
translators) ne sont que des wrappers vers des fonctions du noyau.

On peut clairement dire que la vision de David correspond plus =E0
l'id=E9e originelle de Babel, et semble a premiere vue plus "elegante" :


----------   ---------  ---------------
|        <   <       <  <             |
|  NOYAU <   < BABEL <  < UTILISATEUR |
|        <   <       <  <             |
|        <   <       <  <             |
----------   ---------  ---------------

Ma vision place vraiment plus Babel comme centre de controle de tous
les peripheriques :

----------   ---------  ---------------
|        <   <       <  <             |
|  NOYAU >   > BABEL <  < UTILISATEUR |
|        <   <       <  <             |
|        >   >       <  <             |
----------   ---------  ---------------

Mis a part le fait que la version de David semble plus elegante, il me
semble qu'elle pose quelques problemes, peut etre resolvables, mais
pour l'instant je ne vois pas comment. Je m'explique.

L'utilisateur manipule des ressources (qu'on pourrait assimiler a des
file descriptors). Plusieurs ressources peuvent exister pour un meme
objet : par exemple le fichier /home/thomas/foobar peut etre ouvert
plusieurs fois par plusieurs teams. Toutefois, meme si plusieurs
ressources peuvent exister pour un unique objet, il n'existe qu'UNE
UNIQUE shadow resource pour chaque objet. Les shadow ressources sont
primordiales pour la gestion de la memoire virtuelle (file
mapping). Pour resumer, on peut dire que le noyau travaille avec des
shadow resources et que l'espace utilisateur travaille avec des
ressources.

Une ressource contient au moins un pointeur vers la shadow ressource
correspondante, et une shadow resource contient au moins un pointeur
vers le translator (instance d'une interface Babel) charge de gerer
l'objet designe par cette shadow resource.

Clairement pour resoudre des pages faults, on a besoin de lire des
fichiers, designes au niveau noyau par des shadow resources. Or ces
shadow resources s'intercalent entre les resources et les
translators. Une donnee propre au noyau est donc intercalee entre 2
donnees propres a Babel. Il me parait donc difficile d'avoir un Babel
qui est uniquement la passerelle vers le CPL3. Ou alors il faut
envisager quelque chose de completement different.

A mon avis, il faut un peu repenser Babel, bien reflechir sur sa
place, et le construire en fonction du fonctionnement d'un ou
plusieurs driver (au hasard IDE ou FAT), parce que pour le moment nous
n'avons pas pris en compte l'histoire des shadows resources, et
finalement nous ne savons pas quel role exactement il joue dans le
noyau.

Le noyau a besoin d'objets qu'il doit manipuler : les partitions
servant de swaps, les fichiers mappes en memoire, les disques durs,
etc... On a donc 2 choix clairement different :
 - recentrer Babel a l'interieur du noyau en les faisant interoperer
de la maniere la plus totale.
 - decentrer Babel du noyau, les interfaces Babel n'etant alors que
des wrappers vers le CPL3. Si cette solution est choisie, alors il
faudrait presque construire le noyau entierement sans se soucier
AUCUNEMENT de Babel. Les interfaces Babel programmees ensuite de
chargeront juste d'offrir une passerelle vers le CPL3.

Actuellement, Babel n'est dans ni l'une ni l'autre des deux solutions,
un peu a cheval entre les deux.

J'attends avec impatience vos remarques et suggestions.

Thomas
--=20
PETAZZONI Thomas - thomas.petazzoni@enix.org - UIN : 34937744
(Perso)      http://www.enix.org/~thomas/
(KOS)        http://kos.enix.org/=20
(Club LinUT) http://club-linut.enix.org