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

[Thomas Petazzoni]

> Il faut partir sur cette base, et non pas chercher l'abstraction
> ultime, celle qui sera peut-etre utile aux applications, mais /que/
> aux applications entre elles (style CORBA, ...).

Il est vrai qu'il ne faut pas perdre de vue le fait que Babel n'est
qu'une sorte de Corba minimum, uniquement destine a permettre aux CPL3
d'agir sur les objets du noyau par le biais de methodes. Ce n'est que
cela.

> Je veux bien qu'on definisse Babel, aka broker generique. Mais faut
> penser a le specialiser *des maintenant* pour la gestion OS. "BabelOS"
> dans la suite. Ca nous aidera a eviter de trop extrapoler sur la
> genericite (non)souhaitee de Babel. J'explique dans la suite ce que
> j'entends par BabelOS.

C'est effectivement une chose a preciser : que veut-on que soit Babel ?
Si on veut que ce soit un ORB generique, alors il faudra un Babel-light
(aka BabelOS) pour le noyau.

> En fait, je percois que ce que tu veux derriere, c'est une classe
> racine qui ne dispose que des methodes d'introspection et
> d'identification, et pas de methodes pre-definies style
> read/write. Si c'est ca, j'ai exactement la meme vision des choses
> *pour Babel*.

Tout le monde est d'accord sur ce qu'on appelle la root_interface il me
semble.

> Ca, on l'a deja en partie (Babel). En tous cas, on a idee de ce a quoi
> on veut que ca serve (repertoire d'interface, moyen d'identifier,
> reste l'introspection et la verification des types). Maintenant, il
> faut definir la methode d'action sur les ressources gerees par le
> noyau en utilisant l'infrastructure Babel de base : BabelOS.

Effectivement.

> Appelons ca BabelOS, constitue d'objets Babel (aka le "n'importe quoi"
> en question). BabelOS se charge de la representation et de
> l'identification des ressources *systeme*.

On complexifie nettement pour ma petite cervelle. On avait du Babel,
maintenant du BabelOS, je vais m'y perdre. Mais bon, je vais
m'accrocher, promis :)

> Je pense comprendre et meme etre d'accord.

La aussi tout le monde est d'accord :)

> L'interface Babel, c'est avant tout des methodes. Ca ne devrait etre
> *que* des methodes. Des donnees privees peuvent etre associees a cette
> interface. Ces donnees ne devraient etre accedees (et accessibles ?)
> *que* par les methodes de l'interface. Les methodes, elles, sont
> accessibles par tout le monde. Il est hors de question de mettre en
> place des mecanismes de protection des methodes (private, protected),
> ou alors il faut utiliser un langage adapte (C++).

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

> interface Babel = { methodes publiques, variables privees d'interface }
> // Aucune methode privee, aucune variable d'interface publique

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

> instance Babel = { lien vers interface, variables privees d'instances }
> // aucune variable d'instance publique

Parfait d'accord.

> Si on fait bien la difference entre Babel (broker generique) et
> BabelOS (gestion de ressources systeme), j'insiste (en changeant un
> peu ma terminologie), on devrait avoir :
>   - L'identifiant de l'*interface*
>   - L'identifiant de l'*instance* de l'interface
>   - L'identification des *ressources* gerees par l'instance

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

> Donc, dans BabelOS, on a :
> 
> La _classe de services_ (une Interface Babel) :
>   - definit les methodes de manipulation des services
>   - est capable d'identifier/lister les services dont elle
>     dispose
> Les services (des Instances Babel de l'interface "classe de services") :
>   - implantent les methodes de manipulation definies dans la classe de
>     services => jouent le role de "driver"
>   - sont capables d'identifier/lister les ressources dont elles sont
>     responsables
> Arborescence des ressources (Instances d'une interface "ressource" de
> Babel) :
>   - C'est une arborescence
>   - donnees/peripheriques/... (noeud terminal)
>   - lien vers d'autres ressources
>   - repertoires de ressources (noeud non terminal)

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

> Bref, je vois l'architecture BabelOS a 2 niveaux :
>   + Babel : definition de mecanismes d'identification et
>     d'introspections sur les Objets + gestionnaires
>     d'interfaces/instances. Generique.
>   + BabelOS : Interfaces+Instances Babel :
>      + Classes de services / services
>      + Arborescence de ressources

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

>   - des services (aka drivers) qui ne sont pas franchement classes en
>     arboresecence.
> Et d'autres part :
>   - des ressources gerees par des services qui, elles, definissent une
>     arborescence
> Le tout de facon uniforme (= 1 seul objet base), avec juste
> specialisation (=implantation) de l'objet de base.

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

> En clair, je ne vois pas d'exemple de sous-driver de driver. C'est la
> raison des 2 classes de bases (classes de services/services +
> arborescence de ressource) de BabelOS.

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

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

>   - classes de services
>   - services
>   - ressources sous forme d'arborescence avec 3 types de noeuds
>       + noeuds terminaux ("vraies" ressources)
>       + noeuds non terminaux ("repertoires")
>       + renvois ("liens" ~ translators hurd)

A priori j'y vois pas d'inconvenient, mais j'aimerais qu'on avance aussi
du point de vue code, qu'on teste, qu'on voit ce que ca donne au niveau
implementation.

> Pour que les classes de services soient manipulables simplement, il
> faut qu'on ait dans Babel la propriete "une classe est un objet". A la
> maniere de Java. 

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

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

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

et David voit
	file->get()

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

> Je pense qu'il est necessaire de s'orienter vers BabelOS :
>   - Babel + propriete "une interface est une instance de qqch"
>   - BabelOS : 2 types : classes de services/services + arborescence de
>     ressources

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

Amicalement,

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