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

[Thomas Petazzoni]

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

tout a fait d'accord.

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

belle phrase, qui me permet de dire que je suis toujours tout a fait
d'accord avec toi. lorsque julien etait venu a belfort, nous avions
envisage de pouvoir enregistrer teams, threads et autres objets du noyau
dans Babel, que ces objets exportent des methodes, par kill, sendsig...
Ces methodes seraient accessibles en local sur la meme machine
(classique) et pourquoi pas via le rezo ?

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

ce cote 'invocation de methode' j'y tiens vraiment, car le
fonctionnement d'un micro noyau ne me semble pas vraiment valide : on
considere le noyau comme un ensemble de processus qui tournent. en
realite ils ne tournent pas, en tout cas sous Hurd : l'envoi d'un 
message a un server provoque l'election de ce server en tant que
processus. finalement, ca revient a un mecanisme d'interruption.
toutefois, je ne souhaite pas, et je crois que personne ne le souhaite
ici, qu'on se dirige vers un machin avec des ports.

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

la classe mere ca pourrait etre rien.

mother
 |- team
    |- thread
 |- file
    |- peripherique
    |- repertoire
    |- vrai fichier
 |- ...

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

en fait je pense que mon probleme etait mal pose : une fois qu'on a
notre abstraction en objet (qui me semble etre la meilleure) comment
va-t-on representer ca physiquement ?

Babel serait en fait un super VFS. dans /proc on aurait un repertoire
par team, puis un repertoire par thread, puis pour chaque thread on
aurait des noeuds pour avoir des infos, appliquer des choses a un
thread. dans /dev on aurait l'arborescence des fichiers de type
peripheriques, pi le reste ca serait des systemes de fichiers normaux ?

je crois que mon probleme c'est plus cet aspect la.

un autre probleme, plus urgent : si on considere que les teams et
threads doivent etre des objets enregistres dans Babel, faudrait peut
etre s'en preoccuper maintenant, et donc avoir un Babel final. je sais
qu'on a deja quelque chose de fonctionnel, mais je sais aussi que Julien
veut encore changer des choses. je sais qu'on a pas d'IDL. bref, est-ce
viable de continuer a coder alors qu'il faudra *surement* refaire des
choses pour que ca colle avec les interfaces generees par notre IDL ?

ma question c'etait plus cet aspect la je pense.

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