[Kos-dev] Abstraction a la base de KOS ?

[d2]

Hello,

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@ifrance.com> writes:
    Thomas> Sous Unix, on considere que "tout est fichier". Cette
    Thomas> abstraction est pour l'instant celle qui me parait la
    Thomas> meilleure, en effet on peut representer un fichier par un
    Thomas> fichier, un peripherique par un fichier...

Voui.

    Thomas> Julien parlait de "tout est objet". C'est interessant, car
    Thomas> cela introduit plus clairement le principe de methodes a
    Thomas> appliquer sur cet objet
    Thomas> (read/write/open/close). Toutefois, il est plutot complexe
    Thomas> de representer physiquement (sous forme d'arborescence)
    Thomas> des objets. De plus, un fichier peut difficilement etre
    Thomas> considere comme un objet, alors qu'un peripherique peut
    Thomas> l'etre.

Un Fichier *est* un objet dont les methodes sont open/read/write/close
et sont figees. De meme pour un repertoire (autres methodes). On a
alors la reproduction d'une arborescence en disant qu'un objet
repertoire permet d'acceder a des objets fichiers et repertoires par
ses methodes readdir, ...

Pour resumer, quand on dit "tout est fichier", on dit en realite "tout
est objet" *et* on impose en plus une interface donnee, figee, pas
extensible : open/read/write/close/select/poll/ioctl/seek.

Donc l'affirmation "tout est fichiers" est un sous ensemble contraint
et non extensif de "tout est objet".

    Thomas> Un ami de D2 nous proposait durant le LSM l'abstraction
    Thomas> "tout est socket". C'est une autre solution effectivement,

"Tout est socket", c'est exactement le fonctionnement micro-noyau : on
dit pas "socket", on dit "port". Le systeme fonctionne alors par
messages. Nous, on a dit qu'on voulait fonctionner par invocation de
methode.

Je pense que vu de l'utilisateur, il faut considerer que "tout est
objet". Dans Unix, tout est egalement objet, mais tout est objet de LA
MEME classe (open/read/write/close/ioctl/seek). Ce qu'apporte Babel,
c'est la possibilite d'avoir une extension de cette interface : c'est
a dire la propriete de NE PAS faire passer toutes les primitives
"exotiques" par ioctl. C'est a dire la possibilite d'avoir des
sous-classes d'une classe mere (qu'on pourrait appeler "fichier").

Du point de vue fonctionnel, ca veut dire qu'on garde le
fonctionnement par appel systeme "normal" de Unix (invocation de
methode par call gate), en permettant une programmation plus
extensive, claire et robuste etant donne qu'on n'utilise pas ioctl a
tort et a travers, qui est remplace par l'heritage objet. Ca permet
d'avoir des proprietes d'extensivite proches du fonctionnement par
message des micro-noyaux, sans subir les pertes de perf.

La question la-dedans n'est donc pas "tout est objet ou tout est
fichier ?", mais "est-ce que la classe mere de toutes les autres
classes (root) doit etre la classe qui fournit les methodes
"open/read/write/seclect/seek/close" ?  (ioctl remplace par l'heritage
objet) Ou est-ce que ca doit etre plus petit, ou est-ce que ca doit
etre completement autre chose ?". Sachant que de cette classe mere
depend la gestion de toutes les ressources.

Reste donc a savoir quelles ressources on veut gerer. Moi, j'aimerais
pouvoir gerer les processus (kill, getname, ...) avec les memes
mecanismes sur les objets babel, que les framebuffers, les cartes son,
les fichiers, les sockets, les repertoires, la memoire, les mappings,
les semaphores, les fenetres graphiques, ... Bref, a mon avis, une
interface mere "read/write/..." ne permet de pas d'unifier tous ces
besoins : c'est surement "trop gros", et ca se limite au fichiers.

Pour finir : Babel est valable au niveau frontiere cpl3<->cpl0. Mais,
comme tu le soulignes dans ton mail, on a besoin d'un autre type
d'abstraction, a un autre niveau.

Au niveau du noyau proprement dit, une premiere abstraction dont on a
besoin est la definition du driver associe aux segments memoire. Au
contraire de ce qui se passe en cpl3<->cpl0, c'est qqch de totalement
fige : l'interface doit etre la meme pour tous les drivers
segments. On ne parle pas de fichier ni d'objet a ce niveau, mais de
"driver de segment". Babel n'intervient pas a ce niveau.

Ensuite, si on prend le cas du driver SEG_VNODE, lui a besoin
d'acceder a des objets de type "gestionnaire de fichier" (fichier qui
peuvent etre des periph blocs). Ca revient a dire que les drivers
SEG_VNODE s'adressent a des objets cpl0 Babel qui definissent des
methodes precises (read/write/seek). Donc, babel n'intervient ici non
*pas* pour le passage de la frontiere cpl0<->cpl3, *mais* pour la
representation interne de ce type d'objet. De SEG_VNODE, il faut
acceder a cette representation interne, qui *devra* prendra la forme
d'une structure rassemblant des methodes, toutes situees au meme
endroit (memes offset) dans la structure, qqs le type de l'objet. Ca
permet de retomber sur ses pieds, et de retrouver le fonctionnement
"normal" de vnode.

Bref, Babel constitue, grace a l'heritage, une extension propre,
souple, et efficace du VFS, generalisable a d'autres ressources que
les fichiers, tout en definissant un sous-ensemble adapte a la couche
vnode de VM.

C'est mon point de vue. Comme c'est tres peu corrobore par
l'experience, c'est sujet a remise en cause.

Bonne journee,

-- 
d2