BabelOS (was Re: [Kos-dev] developpement de babel... abstraction (suite))

[d2]

Bonjour,

Je ne sais plus pour quelle raison, on avait decide que dans Babel on
appellerait :
  "interface" -> classe
  "instance"  -> objet (instance de classe)

"interface" dans le sens ou tout ce qui est visible de l'exterieur,
c'est une liste de methodes. Au niveau de chaque instance d'interface,
rien n'empeche d'avoir acces a des variables d'interface partagees par
toutes ses instances.

Quant a Babel : il nous permet d'acceder aux peripheriques geres par
le noyau depuis le cpl3. Babel joue le role de "passerelle" cpl3-cpl0 ;
c'est une version plus propre des appels systemes classiques, par
l'utilisation d'interfaces pour identifier les methodes a appeler. Le
principe fondamental reste le meme que les syscalls : appel de
fonction (via call gate sur x86), avec des arguments.

L'idee avec Babel, c'est de pouvoir avoir une interface d'acces aux
peripheriques, c'est a dire une liste de methodes, qui soit adaptee a
chaque peripherique. Pour l'instant (ie sous Unix), quand on veut
changer la frequence d'echantillonage de la carte son, il faut faire
un ioctl(). Et on utilise toujours ce meme ioctl() quand on veut
changer la resolution du framebuffer, les parametres de tel ou tel
driver... C'est l'anarchie complete. C'est ca qu'on veut eviter. On
aimerait que pour les peripheriques de la classe "son", on ait une
methode "set_sampling_rate()" au lieu des macros pour le parametre
"request" de ioctl(). C'est le but de Babel.

La demarche reposerait pas mal sur l'heritage objet, par la
specialisation d'une classe de base. Le but n'est cependant pas de
recreer toute une modelisation objet pour l'OS. C'est pour ca qu'on a
l'intention de limiter Babel a la gestion d'"interface", et de
generation de Stubs cpl3/cpl0 pour que cpl3 et cpl0 s'entendent (se
trompent pas sur la methode appelee).

Ce mecanisme permet de beneficier de certains avantages du passage de
messages (souplesse, extensibilite), sans trop etre penalises par
leurs inconvenients (la lenteur : on garde la technique classique
d'invocation de methode directe, sans serialisation).

Pour le moment, on a un Babel de base qui repertorie des interfaces
(liste de methodes + introspection), et definit un service qui permet
d'acceder 1/ a ces interfaces, 2/ aux instances de ces
interfaces. Reste a faire plein de choses, notamment un generateur de
stubs cpl0 et cpl3 => besoin d'un IDL. On va essayer de faire simple,
c'est a dire que le but final n'est pas de serialiser les arguments
passes aux appels systeme (cf plus loin). Le but est de pouvoir
s'entendre entre cpl3 et cpl0 sur quelle methode appeler quand on veut
effectuer telle operation sur tel peripherique.

Le Babel pur tel qu'on l'imagine maintenant est un peu trop generique
(meta-meta-meta-meta-objet) : il est temps de nous ramener dans le
contexte service/ressources d'un OS "normal", ie un logiciel en charge
de gerer des ressources. Ca serait bien de retomber sur nos pieds, ie
le contexte OS : services (drivers) et ressources. C'est la
qu'intervient l'API BabelOS qui utilise le schema objet Babel. Tel que
c'est barre sinon, on va reecrire un ORB, reinventer la demarche
objet, et s'orienter vers le micronoyau.

BabelOS, c'est donc juste un moyen de classer les ressources
accessibles par l'utilisateur, et un moyen de recenser et d'identifier
les methodes qui y accedent en utilisant les fonctionnalites Babel.

Bref, ce n'est qu'une generalisation simple, une "dynamisation" des
syscalls statiques classiques (a la Unix). Derriere BabelOS, le but
est toujours d'invoquer des fonctions en leur passant des
parametres. BabelOS/Babel se charge d'identifier les fonctions en
question.

En ce qui concerne les parametres passes aux methodes, on garde
l'approche monolithique classique : pas de verification du typage des
parametres passes aux methodes. La seule verification existante se
passe du cote cpl0 : c'est une verification de coherence, de validite,
de vraissemblance des donnees fournies. Esentiellement : verif
validite des adresses des pointeurs passes en parametres.

Pour detailler : en run-time, Babel ne s'occupe pas du typage des
parametres passes aux methodes. C'est le role du compilateur de se
soucier de ca en compile-time : Babel devrait etre associe a un
generateur de stubs qui genere les .h necessaires pour representer les
services sous forme de table de methodes *signees* (tous les types des
parametres parfaitement definis). Evidemment, ca n'empechera pas un
utilisateur de forcer le systeme en fournissant en run-time des
donnees tordues => la methode cpl0 qui sera derriere devra faire les
verifications necessaires (idem Unix de base). Donc rien de
revolutionnaire cote fonctionnel, mais on ajoute de la souplesse et de
l'uniformite dans la gestion des ressources.

Pourquoi ne pas faire les verifications de type des parametres passes
aux methodes en run-time ? Parce que 1/ ca necessiterait de pouvoir
representer des structures arbitraires. Ca c'est pas genant. Mais
surtout 2/ parce que ca necessiterait de soit a/ serialiser les
donnees, soit b/ demander au noyau de remplir lui-meme des structures
d'echanges avec les types elementaires du style :
  set_field(struct_id, "task.name", (char*)"la Tache");
Dans le premier cas a/ : un petit overhead cote utilisateur pour
serialiser et cote noyau pour interpreter, et dans le cas b/ : un plus
gros overhead lie a la quantite d'appels systeme intermediaires
engendres. Pour un controle strict (par le noyau) des types des donnees
echangees, je ne vois que ces 2 solutions.

Nous, on a choisi de faire comme dans Unix : verification de la
vraissemblance des parametres passes cote cpl0, plutot que vraie verif
des types des donnees passees en parametre.

Bref, BabelOS/Babel n'est qu'une generalisation simple des syscall
statiques, sans verif semantique.


Bonne journee,

-- 
d2