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

[d2]

Bonjour,

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@ifrance.com> writes:
    Thomas> C'est effectivement une chose a preciser : que veut-on que
    Thomas> soit Babel ?  Si on veut que ce soit un ORB generique,
    Thomas> alors il faudra un Babel-light (aka BabelOS) pour le
    Thomas> noyau.

Babel => moyen de representer des interfaces (liste de methodes) +
repertoire d'interface pour retrouver ces methodes + liste des
instances de ces interfaces.

Babel est donc un mecanisme de gestion d'objets. Se limite a implanter
2 choses : le repertoire d'interfaces, et le root_interface.

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.

En gros, Babel est une architecture, et BabelOS est une API Babel pour
faire de l'OS.

    Thomas> Boah la, je crois qu'il faut pas trop s'embeter : chaque
    Thomas> driver doit pouvoir par un moyen ou par un autre dire
    Thomas> explicitement quelles methodes il veut "exporter". Ou plus
    Thomas> exactement, on a une interface, et seules les methodes
    Thomas> explicitement citees dans l'interface sont enregistrees
    Thomas> dans Babel. Donc point de vue securite, on peut imaginer
    Thomas> avoir des fonctions internes au driver sans aucun
    Thomas> probleme.

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

L'ensemble :
   classes de services (Interface Babel) + services (driver lie a une
   interface = instance Babel d'une classe de services) + arborescence
   de ressources (instances d'une interface ressource)

=> Constitue les 2 types Babel definis dans l'API BabelOS.

    Thomas> J'avoue que je ne vois pas bien quelles peuvent etre ces
    Thomas> variables privees d'interface. Le probleme avec ces
    Thomas> histoires de variables privees, c'est que deja on fixe une
    Thomas> interface comme contenant quelque chose. Or pour moi une
    Thomas> interface, c'est uniquement une liste de methodes.  Ceci
    Thomas> etant dit, si vous pensez qu'il y a besoin de telles
    Thomas> variables privees, vous devez avoir une bonne raison. Un
    Thomas> exemple concret ?

Une interface, vue de l'exterieur, ce n'est qu'une liste de
methodes. Mais ces methodes, elles peuvent agir sur 2 choses :
  - l'instance sur lesquelles elles sont invoquees => variables d'instances
  - l'interface de l'instance => variables d'interface, partagees par
    toutes les instances de l'interface

Des exemples ? Une variable d'interface, ca peut servir a maintenir un
compteur de references = nombre d'instances de l'interface. Ca peut
servir a dire qu'on n'a max 1 seule instance par interface, et a y
acceder (tres utilise en Java avec les fenetres par exemple, pour etre
sur de ne pas relancer des fenetres deja visibles).

    Thomas> c'est un peu vague de dire identification des ressources
    Thomas> non ? Je prefere la terminologie de Julien qui consiste a
    Thomas> dire "numero de methode".

Non.

  + methode = element d'une interface => niveau architecture Babel

  + ressource = entite (instance Babel) geree par un service (driver)
    = methodes+donnees => entite de l'API BabelOS

    Thomas> J'avoue que je vois pas bien qu'est-ce que cela change par
    Thomas> rapport a du Babel "normal".

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.

On se situe a 2 niveaux differents. Un driver est un objet Babel,
l'arborescence des ressources d'un driver est une serie d'autres
objets Babel. Ces 2 entites Babel definissent BabelOS.

    Thomas> vous auriez pas encore plus complique ? Non, plus
    Thomas> serieusement, je vous rappelle que nous ne voulons pas
    Thomas> placer un ORB dans le noyau. Notre objectif initial est de
    Thomas> trouver un moyen clair et propre d'eviter le ioctl, et
    Thomas> d'organiser l'exportation des fonctions du noyau vers le
    Thomas> CPL3.

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.

    Thomas> C'est pour cela que tu proposes d'avoir deux choses : un
    Thomas> arbre des ressources d'une part, et une liste de services
    Thomas> d'autre part. Chaque noeud de l'arbre des ressources etant
    Thomas> lie a un service par une sorte de translator.

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.

    Thomas> On pourrait citer klavier qui est un sous driver du driver
    Thomas> i8042. Le driver de CD SCSI est un sous driver du driver
    Thomas> carte SCSI, lui meme un sous driver du PCI.

Ce n'est pas une relation de "possede un ou plusieurs" comme dans une
arborescence (une ressource possede 1 ou plusieurs sous-ressources),
puisque les 2 drivers ne sont pas homogenes (pas la meme
interface). Par contre, c'est une relation de "utilise les services
de". Ca peut etre represente par une donnee speciale dans le driver.

    Thomas> Encore que ce soit discutable. Il est vrai que vouloir
    Thomas> absolument arborescencer (verbe transitif direct, "Classer
    Thomas> sous forme d'arborescence", Robert edition 13/07/2001) les
    Thomas> drivers est un peu stupide. Ce n'est pas un classement
    Thomas> naturel, comme celui des ressources.  Ca ferait un peu
    Thomas> force, et souvent nous ne saurions pas trop comment
    Thomas> arborescencer ces drivers.

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.

    Thomas> je crois que julien avait plutot interface = classe
    Thomas> instance = objet Avec interface != instance.

Il faudrait creuser ce point. Ca me parait important.

    >> htdocs/index.html est un objet *sur lequel* on peut invoquer la
    >> methode GET : c'est une _ressource_ sur laquelle la *methode*
    >> GET, *implantee* dans le _service_ 'http' et *definie* dans la
    >> _classe de service_ 'web', peut etre invoquee.

    Thomas> Julien voit donc protocols->http->get(file)

    Thomas> et David voit
    file-> get()

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

    Thomas> Question a David : pourquoi ton file serait plus lie au
    Thomas> protocole HTTP qu'au protocole FTP. Je peux tres bien
    Thomas> HTTPise ce fichier ou le FTPise, ou le DCCise. Alors
    Thomas> j'aurais autant de liens a partir de ce fichier, que de
    Thomas> protocoles applicables a ce fichier ?

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

    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 ?

Bonne journee,

-- 
d2