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

[Fabrice Gautier]

On 13 Jul 2001 14:26:48 +0200
d2 <David.Decotigny@irisa.fr> wrote:

Je résume

> Quant a Babel : 
Ca gère les appels systèmes.
 
> L'idee avec Babel, [...]
c'est de remplacer les ioctl par des interfaces plus adaptés.

> La demarche reposerait pas mal sur l'heritage objet [...]
mais seulement pour les interfaces noyaux/user

[...]

> 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.

Ok, en fait quand tu dis 1/ accéder aux interfaces je suppose que tu
veux dire accéder aux éventuelles variables de classe de ces interfaces
(Je suis pas trop sur pour quoi y en ai aurait vraiment besoin mais
admettons)

> Reste a faire plein de choses, notamment un generateur de
> stubs cpl0 et cpl3 => besoin d'un IDL.

La j'ai un peu de mal... qu'est-ce tu appelles IDL ici? Tu veux
modéliser toutes tes interfaces dans le language IDL de Corba ou c'est
un terme générique pour dire qu'il faut un moyen de mdéliser ces
interfaces ?

Pourquoi pas juste définir les interfaces en C ? Est-ce que tu veux
aussi avoir le coté multi-language de CORBA directement lié a Babel ?


> C'est la qu'intervient l'API BabelOS qui utilise le schema objet Babel.
Cette API définira donc des interfaces (en "IDL") vers les "services"
offert par le kernel et les drivers.
> 
> 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.

Hum.. qd tu dis "resources accessibles à l'utilisateur" tu veux dire
telle carte son, tel disque etc... des trucs de haut niveau, (par
opposition a des resources de bas niveau utilisés par ces drivers, genre
irq, channel dma, region de mémoire etc..)


> [...] BabelOS/Babel se charge d'identifier les fonctions en question.[...]

Quelle genre d'identification? 
D'un coté j'ai un driver, qui exporte une interface BabelOS, qui
l'enregistre d'une manière ou d'une autre auprès de Babel. (avec un nom
j'imagine, une nom de fichier par exemple)
De l'autre un process user, qui pourra -eventuellement- demander à Babel
la liste des services (ou instances) disponibles, et qui récupéras une
reférence vers le service qu'il désire utiliser ( = un pointeur vers
l'instance en question) et ensuite il appeleras les méthodes de
l'interface correspondante avec un appel tout bete genre
ref->set_sample_rate.

> pas de verification du typage des parametres passes aux methodes.
> La seule verification existante se passe du cote cpl0
Ca parait logique, de tute façon faut pas faire confiance a des
vérification faites en CPL3.

A ce niveau petite Question:

Babel/BabelOS a une partie noyau (pour ce qui est des drivers
s'enregistrants) et une partie user, style la partie syscall de la libc ?

> 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).

Ouias, le coup du génératzeur de stub je digère pas encore tout à fait.
Pour quoi ne pas écrire les interfaces directement sous formes de .h ?


> Pourquoi ne pas faire les verifications de type des parametres passes
> aux methodes en run-time ? [parce que]

Je comprend pas trop ce que tu entends par vérification des types en
run-time. Tous les paramètres vont de toute façon passer par tes
call-gates donc je vois quoi on peux vérifier, à ce niveau la les
paramètres sont des octets à la queuleuleu.

Enfin sinon c'est (plus) clair et j'aime bien les concepts. T'as les
idées d'interfaces maintenant ?

En gros pour faire des interfaces compatibles Unix, il suffit de
regarder les ioctls exisantes et de les transformer en interfaces.


J'ai tout compris là ?

-- 
Fabrice Gautier <gautier@email.enstfr>