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

[Thomas Petazzoni]

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

et elles etaient bien ces vacances ?

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

il est vrai que si l'on veut faire quelque chose de vraiment mieux que
Unix, cad :
	1. pas de ioctl() fourre tout
	2. un /dev/ plus propre (ala devfs)
	3. la possibilite de gerer non seulement des peripheriques, mais aussi
d'autres objets (thread, team...)

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

Il faut quand meme definir une interface de base, que d2 appelle
root_interface, avec les primitives de base. Pour moi, ces primitives ne
seraient pas read/write/close/open/ioctl comme sous Unix, car cela est
bien trop rigide et exclu des objets non geres par Unix. Cette interface
de base serait presque rien : juste des primitives d'introspection, que
tous les objets doivent proposer. Genre get_name(), get_type(),
get_methods()....

Ensuite l'interface de l'objet peut se specialiser terriblement.
(heritage).

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

Je pense qu'il ne faut plus considerer des flots de bits. Car si l'on
compte gerer des teams, des threads comme des objets, alors il n'y a
plus d'histoire de flot de bit.

> La notion d'interface permet de determiner l'essence, la nature, elle
> constitue un artefact dont l'instance est la
> materialisation. 

j'aime beaucoup cette phrase. C'est a noter pour les documentations, car
elle explique bien ce qu'est une interface, et ce qu'est une instance.
Chose que mon mince cerveau avait bien du mal a discerner au depart.

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

Je ne pense pas que ce soit le point faible, mais c'est bien evidemment
la chose sur laquelle il faut reflechir.

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

j'en parlais plus haut effectivement. vraiment des choses de base, qui
n'imposent rien quant a la nature de l'objet.

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

la matrice ou il evolue, va falloir m'expliquer la ! une simple
reference a un film, ou une allusion bien plus complexe que je ne saisis
pas ?

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

oui ca aussi j'avais bien compris. l'interface n'est que purement
virtuelle, et la concretisation de cette interface vient avec
l'instanciation, c'est a dire la creation d'une instance.

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

effectivement, il m'avait aussi semble que d2 avait un peu perdu son
latin en ecrivant ces quelques lignes.

A mon avis, on a besoin de 
	1. numero d'interface
	2. numero d'instance
	3. numero de methode

Et pour les trouver depuis le CPL3, on va faire appel a un merveilleux
generateur d'IDL qui nous pondra une interface pour le CPL0, et un stub
pour la libc du CPL3.

Deux questions a propos de cet IDL :
	1. une question generale : mon IDL me genere a partir d'un fichier de
description de l'interface, un fichier .c qui contient les proto des
fonctions, et qu'il ne reste plus qu'a remplir. Si je veux changer
l'interface (dans le fichier de description), que je dois regenerer le
fichier .c. Je  dois le remplir de nouveau ? Si oui, et je pense que
c'est le cas, c'est vraiment pas pratique de se tromper, nan ?
	2. Comment vont se gerer les stubs au niveau CPL3 ? Il faudrait pas
qu'on ai besoin de recompiler la libc a chaque fois qu'on ajoute une
fonctionnalite dans le systeme. Pour un OS qui se veut dynamique, ca
serait un peu pourri !


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

Mais pourtant /home/mejj/foo.bar est un objet : sur un fichier on peut
faire open/close/read/write/seek... Donc on a encore a faire a un objet.

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

donc pour toi on ne peut pas faire 
	file->read()
	mais plutot filesystem->readfile(file)
en resume et en bref.
le filesystem est donc un protocole permettant d'acceder de maniere
organisee a un bordel de donnees brutes.

Amicalement,

Thomas

PS : concernant les logos julien
	- project_kos_nuechtern_gross.gif : j'aime le design, mais c'est
beaucoup trop bleu pour moi.
	- project_kos_nuechtern_gross.png : j'aime beaucoup. mais sur un T
Shirt je pense que je le fond noir c'est bof. enfin en tout cas moi
j'aime pas trop. mais sinon design pas mal.
	- project_kos_nuechtern_klein.gif : mettre un truc anime sur un T
Shirt. c'est interessant. non je deconne, je suppose que c'etait plutot
pour le site web. La pareil, le bleu est trop agressif a mon gout.
Pourquoi pas reprendre le vert actuellement utilise dans le site Web ?

Perso, un project_kos_nuechtern_gross.png, sur fond blanc (et encore sur
noir ca peut donner), mais surtout avec l'URL http://kos.enix.org ca le
fait !
-- 
PETAZZONI Thomas
thomas.petazzoni@meridon.com     UIN : 34937744
Projet KOS : http://kos.enix.org
Page Perso : http://www.enix.org/~thomas/