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

[Thomas Petazzoni]

> c'est de remplacer les ioctl par des interfaces plus adaptés.

Oui et un peu plus si possible (pas un seul read() mais un appel plus
direct a la methode directement concernee par la ressource en question,
voir mail Julien).

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

Oui et c'est important. L'idee originelle de Babel est "passerelle
CPL3=>CPL0".

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

L'IDL ce n'est qu'un outil pour parvenir a nos fins. L'avantage d'un
IDL, c'est qu'il genere a la fois l'interface et le source *vide* pour
le CPL0, et le .h (stub) pour le CPL3.
C'est simplement un outil pour moins s'embeter :)

Mais a la compilation, tout sera du C, bien sur :)

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

Si j'ai bien compris, oui. Les histoires d'IRQ, DMA, region memoire
c'est la cuisine interne au noyau. Ce qui m'ennuie avec le terme
ressource, c'est que ca peut etre n'importe quoi.

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

Toujours pareil, si j'ai bien compris, grosso modo c'est ca. Mais cette
sorte de premier lookup des methodes disponibles devrait etre inutile
grace au stub CPL3.

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

Babel/BabelOS est dans le noyau, le syscall n'est qu'un moyen comme un
autre d'acceder a ce Babel. Si on decide de faire des appels a
Babel/BabelOS depuis un reseau, ca ne devrait pas poser de problemes
speciaux :)

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

Trop *chiant*.

Amicalement,

thomas
-- 
PETAZZONI Thomas
thomas.petazzoni@meridon.com     UIN : 34937744
Projet KOS : http://kos.enix.org
Page Perso : http://www.enix.org/~thomas/