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

[Thomas Petazzoni]

> Babel => moyen de representer des interfaces (liste de methodes) +
> repertoire d'interface pour retrouver ces methodes + liste des
> instances de ces interfaces.
> BabelOS => propose les interfaces Babel de base necessaires a la
> gestion OS : exporte les 2 interfaces Babel de base (au dessus de
> root_interface) utiles pour la passrelle cpl3-cpl0 (sous forme
> d'invocation de methode). Se situe "au dessus" de Babel.

Babel => generique
BabelOS => surcouche de Babel pour l'adapter specifiquement pour les OS
(adapter pas au sens bricoler bien sur).

> Ok, ca c'est pour le driver. Ca colle bien a Babel. Mais un driver
> gere des ressources qui lui sont associees. Pour ces ressources, on a
> besoin d'une interface Babel : l'"arborescence de ressources".

arborescence des ressources ? pourrais-tu definir une liste plus ou
moins complete des ressources, et de leur lien au niveau arborescence. A
priori pour les ressources, je vois thread/team, fichiers,
peripheriques. C'est bien ca ?

> Babel, ca definit une approche objet generique (repertoire
> d'interfaces, lookup pour appel de methodes). BabelOS, c'est la boite
> a outils des objets Babel necessaires a la passerelle cpl3-cpl0 dans
> un OS.

Est-ce que l'on veut que Babel soit une chose generique ?
Personnellement il me semblait que Babel c'etait le gestionnaire des
ressources (aka le collecteur de methodes) du noyau. Je ne voyais pas un
broker generique, que l'on ait besoin de specialiser. Est-on bien sur de
ce que l'on veut que Babel (tout court) soit ?

> C'est pour ca que j'essaye de nous ramener au niveau de nos
> besoins. C'est pour ca que j'ai parle de BabelOS. Comme ca, pour
> definir Babel, on garde a l'esprit les besoins qu'on a reellement dans
> BabelOS. Ca evitera de trop meta-meta-meta-iser Babel en se disant que
> "tel mega truc de la mort generique servira peut-etre". On devra se
> limiter en priorite aux besoins de BabelOS, et pas chercher a aller
> plus loin dans un premier temps. Tout ca pour eviter que Babel ne se
> transforme en CORBA bis.

Un paragraphe important, a se rappeler lorsque l'on travaille sur Babel
: on veut juste gerer des objets d'un noyau, qui sont a priori des
objets assez simples. Pas la peine de generiser et metaiser tout ca.

> Pas tout a fait : pour chaque service, on a un arbre des ressources
> associees. L'arbre des ressources n'est pas global au systeme : il
> depend (est lie a) chaque service. Ca constitue l'espace de nommage au
> sein de chaque service.

La j'avoue que j'ai du mal.

> Ca peut etre represente par une donnee speciale dans le driver.

Ca correspondrait plus a des dependances donc.

> Je pense la meme chose, mais je suis pas sur de l'absence de
> contre-exemple. Mon meilleur argument est l'absence d'homogeneite dans
> les drivers : j'imagine pas un sous-driver qui utilise la meme
> interface qu'un driver (sur-driver) en rajoutant 1 ou 2 autres
> methodes. Bref, j'imagine pas trop d'heritage avec ajout de methodes
> entre implantations de drivers. J'imagine bien 2 drivers differents
> qui ont un ensemble de methodes communes : c'est le principe d'avoir
> plusieurs services differents par classe de services. Mais j'imagine
> pas un service B sous-service d'un service A.

=> pas de hierarchie de drivers, mais des liens de dependances.

> Moi je vois plutot :
>   file->get_parent_service(file)->get();

et le parent_service sur un file, c'est quoi ext2, vfat des choses comme
ca ?

> j'aurais 2 ressources differentes (c'est le cas en pratique) :
>     :web:http:/path_www/file
>     :web:ftp:/path_ftp/file
> (ou :net: d'ailleurs a la place de :web:)

Ai encore un peu de mal avec les liens entre ressources et service
correspondant :)

>     Thomas> Voui, et je suis chiant, il faudrait aussi s'orienter vers
>     Thomas> le coding.  Parce que Babel est un gros morceau, et
>     Thomas> j'aimerais pas qu'on se retrouve bloque par quelque chose
>     Thomas> que nous avons prevu autant de temps a l'avance, ce serait
>     Thomas> bete.
> 
> D'accord. Au programmes des prochaines rencontres kossiennes ?

Bien sur, mais uniquement dans le cas ou ca avance a la methode "on the
fly". Il faut avancer du point de vue coding. Sinon on va encore passer
une semaine a discuter de Babel, a pas etre d'accord alors qu'on
l'est...

Amicalement,

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