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

[Thomas Petazzoni]

> certainement, c'est un passage oblige, tout ce que je voulais dire
> c'est qu'il ne faut pas oublier que l'objectif reste ne pas perdre la
> polyvalence des objets, mais de trouver le moyen de structurer pour
> les exploiter au mieux.

Mais veux-tu un Babel generique (aka capable de gerer n'importe quel
objet), ou preferes-tu un Babel concu specifiquement pour notre probleme
? 
A mon avis, au depart on etait parti pour la seconde option, et il ne
faut pas la perdre de vue : l'objectif final de Babel c'est pour le
noyau d'un OS. Ce n'est pas destine a gerer des objets aussi complexes
que dans des applications (Corba, DCOM..).

> a ce stade de ma lecture je ne comprends pas encore bien la nuance
> entre babel et babelOS, babel serait le concept, une sorte
> d'architecture et babelOS une sorte implementation ?

j'ai toujours un peu de mal avec cette nuance Babel/BabelOS, mais ca va
venir :)

> je suis absolument d'accord avec toi. chaque instance dispose de ses
> propres variables, l'interface defini uniquement les methodes (=
> services = primitives), j'y ajoute des donnees que j'appelle privee,
> en realite c'est pas le bon mot, je veux plutot penser a des donnees :
> partagee ( ou shared puisque le code est ecrit en anglais ). ce sont
> des variables commune a toutes les instances d'une meme interface, par
> exemple le nom de l'interface est commun et accessible par toute les
> instances qui dependent de cette interface.
> l'autre tache de l'interface est de definir la structure de donnees
> "privee", c'est a dire propre ou personnel a chaque instance, pour que
> l'interface puisse fonctionner.
> je tiens a dire que actuellement, babel, utilise deja ces principes et
> fonctionnent, ils sont deja tous implementes (cf code).

Effectivement, cette vision interface/instance sur laquelle nous sommes
partis est deja implemente. C'est vraiment l'element a la base de Babel
me semble-t-il.

> interface babel
>   {
>     - methodes (= primitives = services de l'interface)
>     - donnees partagees (=shared) definition de la structure des
>     - donnees privees (= structure des variables personnelles, propres
>       a chaque instance)
>   }

Pourquoi les donnees privees, propres a chaque instance, sont dans
l'interface ? C'est en quelque sorte des "trous" vides, differents mais
presents pour chaque instance. D'ou leur presence dans l'interface ?

> je crois comprendre que ton inquietude et que la contrainte
> supplementaire a babelos est la gestion des ressources, si je
> comprends bien ta definition d'une ressource est par exemple un
> fichier sur un systeme de fichier.
> la (enfin une des) grandes questions est je crois comment va-t-on
> reagir a une commande read ou write sur un fichier ?

Oui je crois que notre gros probleme c'est ca : on a une entite (un
fichier notamment) et on veut effectuer telle ou telle operation de base
sur cette entite. Pour cela il faut retrouver a quel protocole d'acces
est soumis cette entite (protocole ext2, protocole HTTP...).
Il faut a partir de l'entite, retrouver le protocole correspondant.

C'est a mon avis le point important que nous avons oublie lors de la
conception de Babel. Il me semble avoir essaye de vous poser des
questions tres pratiques, genre comment on va faire open sur tel
fichier. Je suis certain que vous vous en souvenez, j'etais plus que
lourd car je ne comprenais pas grand chose a vos concepts objets, et moi
je voulais du pratique : on a une entite, on veut retrouver le protocole
correspondant.

> 1. l'interface ext2 definit la methode write,
> 
> 2. une instance de cette interface est construite definissant par ses
> variables personnelles qu'elle doit agir sur une partition lambda.
> 
> 3. une ressource, est un element manipulable par cette instance, c'est
>    un element (un flux de bits) qui se situe sur cette partition
>    lambda.

Je comprends mieux la definition de ressource : tout ce qui est
accessible, manipulable par une instance d'une interface donnee.

> c'est un peu *cru* vu comme ca, mais l'idee est derriere, je crois que
> la ressource, n'est qu'une donnee brute, on peut la representer sous
> une forme d'arborescence comme on le fait sur un systeme de fichier,
> mais ceci n'est qu'une representation. le nom d'un fichier ne permet
> qu'a le retrouver ce n'est qu'un identifiant. l'instance doit donc
> permettrent de retrouver cette ressource mais cette ressource est
> manipuler par l'instance, elle n'est pas un objet mais appartient dans
> l'absolu au donnee privee de l'instance ou plus exactement au donnee
> que l'on definit comme manipulable par l'instance, si l'on prend
> l'exemple d'un systeme de fichier.

Je crois que ce n'est pas l'instance qui doit permettre de retrouver la
ressource, mais qu'a partir de la ressource, on puisse retrouver quelle
instance de quelle interface permet de manipuler ladite ressource. (j'en
parlais plus haut).

> en faisant un read(/home/mejj/foo.bar);
> on invoque en realite la methode :
> 
>  instance_ext2_sur_/home->read(identifiant);
>  avec identifiant = /home/mejj/foo.bar

Qui va determiner que /home/mejj/foo.bar et sur la partition X, montee
en /home et de type ext2 ?
La libc certainement, mais est-on d'accord ?

> sous unix, on a un seul appel systeme read(); lors de son invocation,
> il faut que le noyau trouve quel code il doit invoquer en realite pour
> traiter la requete : le code ne sera pas le meme s'il s'agit d'un
> fichier sur une vfat ou sur ext2. le noyau doit donc d'abord executer
> une sorte de pre-handler qui redirige l'appel.

Il me semble que c'est ca.

> dans notre cas, c'est inutile, lorsque l'on invoque notre read, le
> noyau sait deja que le read qu'il invoque est adapte a la
> ressource. car chaque ressource depend d'une instance qui est
> specifiquement destinee a la manipuler.

Oui on fournit directement le numero d'interface, d'instance et de
methode. Pas besoin de rechercher quelle read on veut appeler (celui du
ext2, du vfat, du nfs ?). Toutefois cette recherche doit tout de meme
s'effectuer en CPL3.

Il faudrait imaginer une sorte de liens (comme le proposait d2) qui lie
directement une ressource (/home ici) a l'instance et l'interface
gestionnaire de cette ressource (ici interface_ext2,
instance_partitionX).

> il s'agit alors evidemment de faire tres attention. car il est evident
> qu'il ne faut pas se perdre dans le nom des methodes : on pourra donc
> definir read comme une fonction obligatoire pour toute interface de
> systeme de fichier ou meme pour toute interface.

Il est clair que les interfaces pour les differents systemes de fichiers
se doivent d'avoir les memes methodes de bases. On definit une interface
filesystem, de laquelle vont heriter les interfaces specifiques a chaque
filesystem, en ajoutant aux besoins des "capabilities" propres a leur
fonctionnement. (=> heritage entre interfaces).
Est-on d'accord sur ce point la ?

interface filesystem {
  read()
  write()
  open()
  close()
  mount()
  umount()
  autres_methodes_ai_pas_d_idee()
  ...
}

interface nfs inherit filesystem {
  check_network_connection()
  connait_pas_autre_truc_specifique_nfs()
  ...
}

Par exemple.

> et c'est la que j'en reviens a ce que je disais au tout debut. la
> difficulte est de definir l'interface fondamentale dont toutes doivent
> dependre, sans pour autant empecher aux interfaces d'etre maleable et
> ce que j'appelais "libre".

J'ai deja dit : l'interface *presque* vide tel que c'est actuellement ca
me semble pas mal :

typedef struct method_s
{
  int (*constructor)(struct instance_s *this, void *);
  int (*destructor)(struct instance_s *this, void *);
} b_method_t;

typedef struct interface_s
{
  struct info_s      *info;
  struct method_s    *function;
} b_interface_t;


Manque surement l'introspection (qui es-tu ?).

Pour Fabrice, qui est pas vraiment d'accord sur les donnees privees (ou
plutot partagees) au sein de l'interface, voici une portion de
interface.h :
typedef struct info_s
{
  char *name;
  char *description;
  char *author;
  char **depends;   // interfaces names this interface needs 
                    // i.e : { "babel" , "libc" , "mm" , ... }

  struct version_s {
    int major, minor, micro, patchlevel;
  }version;

  unsigned long interface_size;
  unsigned long data_size;
  unsigned long ref_counter;
} b_info_t;

On a donc bien des donnees appartenant a une interface, et partagees par
toutes les instances :)

> a vrai dire mon attachement est juste insistant pour eviter de se
> perdre dans un vocabulaire que je ne maitriserais plus et dont je
> perdrais les definitions, mieux vaut les fixer et si tenir, neamoins
> je suis toujours a la recherche de mots plus *beaux* :-)

je crois que la recherche de mots n'est pas vraiment l'objectif de KOS,
ni de Babel. plutot que de chercher des mots, pour chercher a discuter
pendant des mois et des mois, nous devrions coder.
Je pense que nous en sommes tous persuades :
  * on a vu auparavant, qu'en general c'est celui qui en cause le plus
qui en code le moins.
  * on a vu que quand on parlait on etait pas d'accord (a cause du
vocabulaire), mais qu'en codant, tout le monde s'accordait. comme si le
langage de programmation nous etait plus familier que le langage naturel
(enfin la ca serait grave quand meme).

> neanmoins il est vrai que la question est essentielle. si on veut
> creer un repertoire /dev et que ce repertoire est gere par un service
> /dev/scsi/host0/[...] ca peut etre amusant :-) (c'est l'oeuf ou la
> poule qui est ne le premier ?)

je crois que le probleme de la poule ou de l'oeuf est insoluble, et
qu'il convient de trouver une sorte de work around, en creeant d'une
maniere peu elegante la poule (ou l'oeuf ?) qui pourra donner naissance
a l'oeuf (ou la poule ?).

> plus serieusement, babel en soit ne represente pas les choses sous
> forme d'arborescence, tu le notes plus haut. on peut donc envisager
> une interface vfs avec une instance, qui se charge de fournir une
> representation acceptable comme on en voit chaque jour. mais alors, si
> une lecture sur un fichier /home/mejj/foo.bar doit invoquer d'abord
> l'instance vfs->read(...) on en revient a cette idee de pre-handler et
> autant revenir a une vision unixienne des syscalls bien statique.

Voui, et je suis d'accord avec julien c'est pas bien. Il est absolument
necessaire d'avoir une representation des choses, ca peut etre sous
forme arborescente, sous forme d'une grande piece dans laquelle on se
balade en 3D, avec des grandes armoires intitulees Team,
Peripheriques... Puis des etageres Disques Dur, Carte Son...

Juste ce petit delire pour montrer qu'effectivement il y a une certaine
*independance* entre Babel (la facon dont on classe les methodes, et on
les retrouve) et la facon dont on les represente pour l'utilisateur
(programmeur ?).

J'ai bien precise une =>certaine<= independance, car nous devons penser
a ca aussi quand on code Babel : se laisser la possibilite de
representer les ressources d'une maniere ou d'une autre.

> si je comprends bien babelos, il a a charge d'organiser l'arborescence
> et de retrouver pour chaque ressource le service capable de le
> manipuler.

Si c'est ca, BabelOS est LA solution a notre probleme.

> il s'agit la d'un probleme auquel je reflechie egalement depuis
> longtemps, et dont je t'avais deja fait par : ma question etait
> justement ce probleme pour executer quelque chose il faut travailler
> *avec* une instance, hors, certaines interfaces dependront forcement
> d'interface de plus bas niveau, par exemple l'interface ext2 dependra
> d'une interface driver_de_disque. il faut donc qu'une instance puisse
> travailler en particulier avec une instance de plus bas niveau,
> neanmoins, ca n'est pas un probleme, il suffit que l'instance de plus
> haut niveau, connaisse l'identifiant de l'instance de plus bas niveau,
> tout ce joue au niveau de ce fameux pointeur this (cf le code source
> actuel de babel).

y'a une double pointeur depends dans les interfaces. je pense qu'il est
prevu pour ca (et non pour contenir des dependances genre libc, cf
commentaires).

> je crois que sur un point tu as raison, actuellement babel souffre de
> nombreuses faiblesses :

je n'irais pas jusque la.

>   - probleme d'heritage clair liee a l'idee des dependances entre
>     instance comme j'en parle juste au dessus

il faut differencier heritage et dependances.
ext2 depend du driver disque dur.
ext2 herite de l'interface generale filesystem, au meme titre que vfat
ou nfs, ou ftpfs (Hurd).

>   - probleme au niveau de la representation en arborescence. on veut
>     pouvoir presenter tout selon un arbe classique a la unix (du
>     moins, c'est la solution a laquelle on pense, peut-etre faut-il
>     reflechir pour proposer une autre representation des donnees ?,
>     mais c'est un peu trop ambitieux je crois)

bin on pourrait imaginer mon machin en 3D, mais je sais pas si c'est
super pratique, ni a programmer ni a utiliser :)

> pour le premier, je pense qu'on doit trouver des solutions au niveau
> de la programmation assez facilement en reflechissant un peu, pour le
> second, je crois qu'il faut confier cette tache a une interface (qui
> sera evidement instanciee), mais il faut faire attention a ne pas
> tomber dans l'exces que je decris plus haut (retour a une sorte
> d'appel systeme unique).

Voui.

> je voudrais juste rappeler une idee que je trouve importante et meme
> essentiel (c'est a dire qu'elle est la raison meme d'existence de
> babel) : je veux abandonner, le concept d'une seul appel read. en
> realite, il en existe un adapte pour chaque ressource, et je voudrais
> qu'a travers une manipulation au niveau des instances, on puisse
> eviter ce fameux pre-handler qui doit identifier le type de ressources
> avant de pouvoir savoir exactement comment il doit le manipuler.
> c'est la l'interet de babel, mais egalement la difficulte.

L'idee de base ce n'etait pas *vraiment* ca, l'idee de base c'est plutot
: "poubelle ioctl". Mais en reflechissant on s'est apercu qu'on pouvait
peut etre ameliorer d'autres choses. Et bien ameliorons les, je pense
que c'est une bonne idee.

> neanmoins, tu (d2) m'as fait prendre conscience de plusieurs
> importantes faiblesses de babel, son fonctionnement est a preciser,
> neanmoins je ne te cacherai pas que je ne suis pas satisfait avec
> babelos, pour les raisons que j'enoncais plus haut : crainte de
> revenir a une sorte de pre-handler.

Ma solution pour repondre a tes questions : RDV au prochain WE (semaine)
KOS, fin juillet, et CODAGE d'un truc. Meme si ce n'est pas la chose
definitive, CODAGE d'une chose.

> mais tu l'auras compris je veut autre chose que ce que je crois qu'on
> appelle un vfs.

Je ne suis pas sur que VFS => un seul read()

Pour conclure, j'aimerais preciser que j'ai bien conscient d'etre tres
tres lourd d'insister avec le fait qu'il faut coder ces idees, les
mettre a plat, mais je pense que c'est essentiel. Il n'y a que comme ca
qu'on voit les vrais problemes.

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