[Kos-dev] developpement de babel... abstraction (suite)

[Julien Munier]

Bonjour,

voici depuis hier que je suis rentre, et j'ai pris le temps cette nuit
de lire un peu tout ce qui se passe pour rattraper mes semaines de
vacances :-)

je voulais donc reagir a la question : "Abstraction a la base de KOS
?". En effet, je pense depuis longtemps maintenant au concept
d'objet. je vous propose alors les quelques idees qui pourraient nous
interesser pour repondre a la question posee.

comme vient de le rappeler Fabrice : 
 > Je dirais plutot "Tout est un stream de bytes". 
Je pense qu'il faut s'appuyer sur ce 'postulat' de "flot de bits".


si tout est un flot de bits, il est bien entendu qu'avec ca on ne va
pas loin. il est necessaire de structurer ces flots pour en faire
quelque chose de coherent et de comprehensible.

le concept d'objet me semble a ce titre particulierement interessant
car il laisse au principe de flot sa liberte. j'entends pas la qu'un
flot de bits peut representer n'importe quoi, mais qu'une structure
trop rigide comme celle du tout fichier a la unix, prive les flots de
cette polyvalence. au contraire le simple concept d'objet qui lui
laisse toute sa liberte.

je pense qu'il faut etre prudent, il ne faut definir une structure
rigide du concept d'objet, il doit au contraire disposer d'une
structure la plus flexible possible. en realite, il ne s'agit meme pas
de definir la structure de l'objet mais d'en donner l'unite
fondamentale qui permet de le reconnaitre en tant qu'objet.

a travers babel, il s'agit de mettre en forme ce concept, il faut
trouver un moyen de structurer le flot sans l'empecher de representer
n'importe quoi.


La notion d'interface permet de determiner l'essence, la nature, elle
constitue un artefact dont l'instance est la
materialisation. l'interface permet donc de structurer l'objet qui
n'existe qu'a travers l'instance.

il faut donc se concentrer sur l'interface, c'est le point faible de
babel, car c'est l'interface qui limite la flexibilite et la richesse
de la nature de l'instance.

l'interface se doit de respecter l'unite fondamentale dont je parlais
plus haut qui permettra de reconnaitre l'instance comme ayant une
telle nature d'objet.

il s'agit alors de definir les fonctionnalites qui compose cette unite
fondamentale de tout objet (=instance) : les plus essentielles
semblent avant tout l'identification et l'introspection. chaque objet
doit pouvoir s'identifier et egalement permettre de definir ses
fonctionnalites. ainsi il peut etre reconnu et exploite par la matrice
ou il evolue (j'englobe la le noyau comme le niveau utilisateur, et
bien sur de maniere locale ou distante).


un objet ou instance, associe donc a une interface, un bloc de
donnees. l'interface a pour vocation de structurer le bloc de donnee
et de fournir les primitives qui permettent de le manipuler c'est a
dire de l'identifier et d'y appliquer les methodes que l'objet peut
supporter.

si on veut y voir une analogie des class C++ (bof! comme analogie),
l'interface definit avant tout les methodes et les donnees privees de
ce "type" d'objet tandis que l'instance ajoute a ces methodes, un bloc
de donnees. mais pour etre exacte c'est le couple methode/donnees
qu'il faut appeler l'instance.



passons maintenant a un ce que j'ai lu et que je voudrais commenter :

>  :os:proc:/pid=7634/maps
>  :os:config:/max_processes
>  :ipc:sem:/uid=873/id=543
>  :fs:local:/blabla/ble/bli
>  :dev:snd:/card0
>
> C'est a dire :
>  - L'identifiant de la classe
>  - L'identifiant de l'instance de classe (le service)
>  - L'identifiant de l'objet manipule, en suivant la regle de nommage
>    du service (separation par des '/' ou par des virgules, ...)

d'abord il ne faudrait pas se meprendre : 
 - objet = instance
 - service = methode d'une instance (defini par l'interface)
enfin, je parle ici des definitions donnees pour babel.

je voudrais aussi revenir sur la question des systemes de fichiers :

prenons l'exemple d'un fichier foo.bar dans un repertoire d'une
partition ext2 d'un disque dur local d'une machine.

on aurait par exemple /home/mejj/foo.bar

avec /home un point de montage d'une partition ext2
/dev/scsi/host0/bus0/target0/lun0/part5


donc /home est une instance qui associe l'interface ext2_fs et qui a
pour bloc de donnees des informations permettant de dire qu'il doit
manipuler telle partition du disque.

une autre instance pourrait associer la meme interface ext2_fs a une
autre partitions par exemple : /dev/scsi/host0/bus0/target0/lun0/part9




je reflechissais donc a partir de ce que j'ai cite plus haut ou on
appellerait si j'ai bien compris foo.bar un objet. or il n'est pas a
proprement parler une instance d'une interface, l'instance est le
noeud de montage.

alors, je ne sais pas si je me trompe mais peut-etre qu'il y a ici un
malentendu : peut-etre qu'il ne faut pas appeller foo.bar un objet,
c'est a dire une instance. en effet, l'instance est /home/ la
representation mejj/foo.bar est gere par le principe de systeme de
fichier c'est a dire que ce classement est genere et gere par ext2_fs
qui a pour vocation de presenter ainsi l'espace de donnee de
l'instance /home, mais en realite mejj/foo.bar n'est qu'une
representation, c'est en realite uniquement un identifiant d'un bloc
de bits manipulable par l'instance et les primitives qui lui sont
attribue par l'interface dont elle depend.


pour appuyer mon affirmations je voudrais prendre l'exemple d'un
protocole : http. une instance fonctionne comme un protocole (mais en
beaucoup plus evolue), d'un cote on dispose d'une structure et de
primitives : en http par exemple la commande GET (je crois que cette
commande existe vraiment vous me pardonnerez sinon), et a cote, on a
des fichiers que le serveurs web peut envoyer /htdocs/*.html. Ainsi a
travers le protocole on peut faire un GET htdocs/index.html

mais a proporement parler htdocs/index.html n'est qu'une
representation d'un bloc de donnees, le fichier index.html n'est pas
un objet qui peut spontanement invoque la primitive GET du protocole
html.



j'espere etre plus clair.


parmis ceux qui m'auront suivi jusque la, je me permettrai d'aller
meme un peu plus loin : j'ai pris plus haut la convention de nommage
de devfs pour /dev/scsi/host0/bus0/target0/lun0/part5

hors, ce nom est lui meme l'image d'une instance : c'est l'instance
qui associe le driver de disque scsi , a des donnees qui identifient
le host numero 0, le bus 0, target 0, le lun 0 et en particulier les
secteux x a y qui definissent le part numero 5.


donc on a des instances a deux niveaux :

une a un niveau que j'appellerai physique :
/dev/scsi/host0/bus0/target0/lun0/part5 car il s'agit de l'ecriture
physique des blocs de bits et une autre instance a un niveau plutot
logique : qui associe cette instance 'physique' a un niveau logique :
le systeme de fichier ext2




donc pour resumer, je pense que ce qui compte c'est de bien maitriser
la notion d'interface et pour cela de bien definir les besoins et ce
que j'appelais l'unite fondamentale des interfaces.

ensuite d'autres questions se posent : comment on organise ces
interfaces, comment on invoque les services (=primitives) d'un objet
(=instance).


je vous laisse, en attendant vos remarques.


Julien