BabelOS (was Re: [Kos-dev] developpement de babel... abstraction (suite))
Julien Munier
kos-dev@enix.org
Fri, 13 Jul 2001 19:58:25 +0200
Bonjour,
tout d'abord, je tiens a dire que j'ai commence a rediger ce courrier
hier, et que je ne repond qu'au mail de david, je n'ai pas encore pu
reprendre les messages envoyer aujourd'hui (vendredi 13 juillet).
je tenterai neanmoins de repondre a ces courriers tout a l'heure.
>C'est pas faux. Mais ca nous avance pas beaucoup. Ca serait comme
>dire : "tout est "particule", donc etablissons toutes les lois
>macroscopiques de la physique sur la base de la physique des
>particules". C'est satisfaisant pour les phenomenes microscopiques
>(etude de la matiere) ou cosmologiques (etude de l'evolution de
>l'univers). Mais c'est pas suffisamment efficace ni pratique pour
>modeliser les phenomenes macroscopiques classiques (chute des
>corps, thermodynamique, ...). Pour ces phenomenes ni trop fins, ni
>trop grossiers, c'est plus pratique de recourir a une abstraction
>du monde de plus haut niveau. Meme si, dans le cas de la physique,
>ca revient a faire des approximations.
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.
>Il faut partir sur cette base, et non pas chercher l'abstraction
>ultime, celle qui sera peut-etre utile aux applications, mais /que/
>aux applications entre elles (style CORBA, ...). Bon, bref, vous
>l'aurez compris, c'est pas le terme "objet" tout a fait general qui
>me gene. C'est de dire "tout est flux de bits". Faudrait revoir la
>citation de Linus, mais il devait y avoir des smileys ou du 2nd
>degre derriere. En general, Linus n'aime les flux de bits *que* a
>la condition qu'ils ne soient pas "generaux", mais bien formates,
>standardises, utilises dans des formes normalisees. Dans ce sens
>la, j'admets.
la, je veux juste lever les malentendus. je suis absolument convaincu
de la necessite de structurer tout ca, mais je voulais juste
convaincre de la necessite de toujours rechercher des choses simples,
des choses flexibles, evolutives. ce que je veux juste dire, c'est
qu'il faut trouver une facon de structurer qui permette de rendre les
choses coherentes sans pour autant les limiter, je ne donne ici aucune
idee, c'est juste un preambule, je voulais juste rappeler, convaincre,
des contraintes auxquelles il faut songer.
>La, je suis pas franchement chaud. "Liberons l'objet", soit, mais
>pas trop quand meme. Je comprends bien que tu veuilles une
>architecture objet qui nous contraigne le moins possible. Mais il
>faut garder a l'esprit que cette absence de contrainte ne doit pas
>etre "absolue". Sinon, on va vite se retrouver tout perdu, a
>refaire sans arret les memes wrappers. Il faut des maintenant
>penser a BabelOS. Ca nous aidera a definir Babel plus precisement.
j'en suis aussi convaincu.
>En fait, je percois que ce que tu veux derriere, c'est une classe
>racine qui ne dispose que des methodes d'introspection et
>d'identification, et pas de methodes pre-definies style
>read/write. Si c'est ca, j'ai exactement la meme vision des choses
>*pour Babel*.
jusque la on est definitivement d'accord. tout objet devra herite de
cette classe racine (= interface fondamentale ). actuellement, il
s'agit du fichier babel/interface.h
>Ca, on l'a deja en partie (Babel). En tous cas, on a idee de ce a
>quoi on veut que ca serve (repertoire d'interface, moyen
>d'identifier, reste l'introspection et la verification des
>types). Maintenant, il faut definir la methode d'action sur les
>ressources gerees par le noyau en utilisant l'infrastructure Babel
>de base : BabelOS.
>
> Julien> je pense qu'il faut etre prudent, il ne faut definir
> une Julien> structure rigide du concept d'objet, il doit au
> contraire Julien> disposer d'une structure la plus flexible
> possible. en Julien> realite, il ne s'agit meme pas de definir
> la structure de Julien> l'objet mais d'en donner l'unite
> fondamentale qui permet Julien> de le reconnaitre en tant
> qu'objet.
>
>C'est ce que j'appelais root_interface.
absolument voir plus haut.
> Julien> a travers babel, il s'agit de mettre en forme ce
> concept, Julien> il faut trouver un moyen de structurer le flot
> sans Julien> l'empecher de representer n'importe quoi.
>
>J'aime pas le "n'importe quoi" (dans le sens "flux de bits") : le
>noyau va faire n'importe quoi si il doit gerer du "n'importe
>quoi". Le n'importe quoi en question, faut garder a l'esprit que ce
>sera des ressources physiques ou logiques sur lesquelles les
>applications sont en concurrence d'acces. Je pense que c'est a ca
>que tu pensais.
je suis d'accord, la formulation "n'importe quoi" n'est pas forcement
tres heureuse, mais ce que j'entends pas la, est que ces flux de bits,
peuvent representer aussi bien des octets en partance pour une carte
son, que pour une ecriture sur un disque dur. notre tache est de
definir un moyen d'"empaqueter" (dans le sens de structurer) ces
octets afin de disposer de primitives sachant les manipuler, ensuite
les octets peuvent etre n'importe quoi... par exemple l'interface qui
gere une partition ext2 est le paquettage, mais les octets que tu lis
sur une partition peuvent etre n'importe quoi (fichier texte, image,
binaire ou mp3).
>Appelons ca BabelOS, constitue d'objets Babel (aka le "n'importe
>quoi" en question). BabelOS se charge de la representation et de
>l'identification des ressources *systeme*.
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 ?
> Julien> La notion d'interface permet de determiner l'essence,
> la Julien> nature, elle constitue un artefact dont l'instance
> est la Julien> materialisation. l'interface permet donc de
> structurer Julien> l'objet qui n'existe qu'a travers
> l'instance.
>
>Voui.
>
> Julien> il faut donc se concentrer sur l'interface, c'est le
> point Julien> faible de babel, car c'est l'interface qui limite
> la Julien> flexibilite et la richesse de la nature de
> l'instance.
>
>Voui.
>
> Julien> l'interface se doit de respecter l'unite fondamentale
> dont Julien> je parlais plus haut qui permettra de reconnaitre
> Julien> l'instance comme ayant une telle nature d'objet.
>
>Voui.
>
> Julien> il s'agit alors de definir les fonctionnalites qui
> compose Julien> cette unite fondamentale de tout objet
> (=instance) : les Julien> plus essentielles semblent avant tout
> l'identification et Julien> l'introspection. chaque objet doit
> pouvoir s'identifier et Julien> egalement permettre de definir
> ses fonctionnalites. ainsi Julien> il peut etre reconnu et
> exploite par la matrice ou il Julien> evolue (j'englobe la le
> noyau comme le niveau utilisateur, Julien> et bien sur de
> maniere locale ou distante).
>
>Je pense comprendre et meme etre d'accord.
>
> Julien> un objet ou instance, associe donc a une interface, un
> Julien> bloc de donnees. l'interface a pour vocation de
> structurer Julien> le bloc de donnee et de fournir les
> primitives qui Julien> permettent de le manipuler c'est a dire
> de l'identifier et Julien> d'y appliquer les methodes que
> l'objet peut supporter.
>
>L'interface Babel, c'est avant tout des methodes. Ca ne devrait
>etre *que* des methodes. Des donnees privees peuvent etre associees
>a cette interface. Ces donnees ne devraient etre accedees (et
>accessibles ?) *que* par les methodes de l'interface. Les
>methodes, elles, sont accessibles par tout le monde. Il est hors de
>question de mettre en place des mecanismes de protection des
>methodes (private, protected), ou alors il faut utiliser un langage
>adapte (C++).
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).
> Julien> si on veut y voir une analogie des class C++ (bof!
> comme Julien> analogie), l'interface definit avant tout les
> methodes et Julien> les donnees privees de ce "type" d'objet
> tandis que Julien> l'instance ajoute a ces methodes, un bloc de
> donnees. mais Julien> pour etre exacte c'est le couple
> methode/donnees qu'il Julien> faut appeler l'instance.
>
>interface Babel = { methodes publiques, variables privees
>d'interface } // Aucune methode privee, aucune variable d'interface
>publique
>
>instance Babel = { lien vers interface, variables privees
>d'instances } // aucune variable d'instance publique
je tiens a m'excuser, je parle de choses que je maitrise trop mal, je
me suis foutu dedans avec cette pseudo analogie.
neanmoins, il semble que l'on m'ait a compris :
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)
}
instance babel
{
- liens vers une interface dont est depend
- variables privees (=propres =personnelles) (d'ou ce fameux
pointeur this dans le code actuel de babel)
}
nous sommes donc d'accord jusque la.
j'en viens a la question de babelos que je commence a mieux cerner.
en effet, babel, dans son etat actuel permet de gerer des
peripheriques qu'ils soient materielles ou logicielles : on gere
l'ecriture sur un disque, dans la memoire, ou un peripherique logique
comme un /dev/loop par exemple.
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 ?
>Si on fait bien la difference entre Babel (broker generique) et
>BabelOS (gestion de ressources systeme), j'insiste (en changeant un
>peu ma terminologie), on devrait avoir :
> - L'identifiant de l'*interface* L'identifiant de l'*instance* de
> - l'interface L'identification des *ressources* gerees par
> - l'instance
>Sachant que l'interface definit les methodes dispos pour agir sur
>la ressource (read/write, ou up/down, ou map/unmap,
>ou...). L'instance implante (specialise) les methodes de cette
>interface pour les ressource qu'il gere.
je pense qu'il faut dire que l'interface definit les methodes qui
peuvent manipuler les donnees de l'instance, mais aussi les donnees
sur lequels l'instance a un *pouvoir*. la ressources se situe a un
niveau inferieur, elle n'est qu'un identifiant pour localiser un
element, je voudrais citer ici thomas dans son mail qui repond
egalement a celui auquel david repond :
ainsi, si on veut un exemple simple :
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 fixe ainsi mon vocabulaire, en particulier sur la question de
ressource, je sais que tu ne l'entends pas ainsi, d'ailleurs je trouve
que pour ce que je veux definir le mot ressource n'est pas adapter,
mais je veux juste expliquer les differents niveaux que je considere.
dans la suite du document ressource a cette signification, elle
represente une donnees brutes, manipulable par une instance.
je voudrais par ailleurs reprendre l'expression de thomas :
*** thomas a ecrit :
> le filesystem est donc un protocole permettant d'acceder de maniere
> organisee a un bordel de donnees brutes.
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.
ce que je veux dire c'est que par exemple on a un instance qui gere ce
fameux repertoire /home avec par exemple la primitives : read
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
et je pense que c'est justement la l'idee interessante.
(attention, la je vais dire des choses, car je crois que ca marche a
peu pres comme ca, vous m'excuserez sinon)
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.
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.
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.
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".
>Je sais que tu es tres attache aux termes interface/instance. C'est
>valable pour l'architecture Babel = la gestion d'objets. Pour
>BabelOS, on doit se situer a un niveau de specialisation "en
>dessous", puisqu'on doit gerer des ressources /avec/ Babel. C'est
>la raison pour laquelle je ne parle plus d'instance ni d'interface
>dans BabelOS : les entites manipulees sont tous geres par Babel. On
>remarque un mapping fort entre classe de service et interface, et
>entre service et instance.
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* :-)
>Donc, dans BabelOS, on a :
>
>La _classe de services_ (une Interface Babel) :
> - definit les methodes de manipulation des services
> - est capable d'identifier/lister les services dont elle dispose
> Les services (des Instances Babel de l'interface "classe de services") :
> - implantent les methodes de manipulation definies dans la classe
> - de services => jouent le role de "driver"
> - sont capables d'identifier/lister les ressources dont elles
> sont responsables
> Arborescence des ressources (Instances d'une interface "ressource"
> de Babel) :
> - C'est une arborescence
> - donnees/peripheriques/... (noeud terminal)
> - lien vers d'autres ressources
> - repertoires de ressources (noeud non terminal)
>(pour ressources, voir plus loin)
>
>Par exemple :
> :pci:host0:/04/0 ; methodes = { j_en_sais_rien, connais_pas_pci }
> :cpu:cpu0:/frequency ; methodes = { set, get }
> :cpu:cpu0:/cpuid/vendor_id ; methodes = { set, get }
>
> :ipc:shm:uid=657/5677 ; methodes = { get, op, ctl }
> :ipc:sem:uid=657/98 ; methodes = { get, op, ctl }
>Mais c'est trop proche de ioctl. Autre solution plus propre (et
>plus vraie) :
> :ipc/shm:uid=657:5677 ; methodes = { get, release }
> :ipc/sem:uid=657:743 ; methodes = { get, release, up, down }
>Sachant que 'ipc/shm' et 'ipc/sem' sont 2 classes de services
>(interfaces) differentes.
>
>Sans oublier :
> :fs:local:/home/mejj/foo.bar ; methodes = {
>read/write/seek/select } Se charge de traduire cette requete en
>requete vers la ressource precise :
> :blockfs:ext2:/scsi/host0/lun0/part0 ; methodes = {
>read/write/seek/sync } Sachant que scsi/host0/lun0/part0 indique a
>ext2 qu'il doit s'appuyer sur la ressource (lien sous-jacent) :
> :scsi:host0:/lun0/part0 ; methodes = { je_connais_pas_scsi }
>
>Bref, je vois l'architecture BabelOS a 2 niveaux :
> + Babel : definition de mecanismes d'identification et
> d'introspections sur les Objets + gestionnaires
> d'interfaces/instances. Generique.
> + BabelOS : Interfaces+Instances Babel :
> + Classes de services / services + Arborescence de ressources
>
>Soit 2 types Babel a definir dans BabelOS.
>
> Julien> alors, je ne sais pas si je me trompe mais peut-etre
> qu'il Julien> y a ici un malentendu : peut-etre qu'il ne faut
> pas Julien> appeller foo.bar un objet, c'est a dire une
> instance. en Julien> effet, l'instance est /home/ la
> representation Julien> mejj/foo.bar est gere par le principe de
> systeme de Julien> fichier c'est a dire que ce classement est
> genere et gere Julien> par ext2_fs qui a pour vocation de
> presenter ainsi Julien> l'espace de donnee de l'instance /home,
> mais en realite Julien> mejj/foo.bar n'est qu'une
> representation, c'est en realite Julien> uniquement un
> identifiant d'un bloc de bits manipulable Julien> par
> l'instance et les primitives qui lui sont attribue par Julien>
> l'interface dont elle depend.
>
>C'est exactement pour ca que j'ai distingue "service" et
>"ressource" (ou, avec mon ancienne appellation : instance et
>objet).
>
>Comme on l'a vu dans ce qui precede, je pense qu'on ne peut pas
>simplement resoudre nos problemes d'OS avec un broker objet
>generique. Il faut le specialiser en une petite serie (2) de types
>de base, specialises pour l'OS : BabelOS. Dans ce cas, Babel nous
>permet indirectement de resoudre nos problemes, via les 2 types
>introduits dans BabelOS.
>
>Le probleme dans Babel seul, c'est qu'il faut que l'arborescence
>des ressources dans un service puisse contenir des liens vers des
>ressources d'une autre classe de services (~ translators
>hurd). L'ideal serait donc de pouvoir representer l'arborescence
>des ressources de la meme facon pour tous les services, quelle que
>soit la classe des services. Je vois pas de solution a ce probleme
>en utilisant Babel seul. Comment avoir d'une part :
> - des services (aka drivers) qui ne sont pas franchement classes
> en arboresecence.
> Et d'autres part :
> - des ressources gerees par des services qui, elles, definissent
> une arborescence Le tout de facon uniforme (= 1 seul objet base),
> avec juste specialisation (=implantation) de l'objet de base.
>
>En clair, je ne vois pas d'exemple de sous-driver de driver. C'est
>la raison des 2 classes de bases (classes de services/services +
>arborescence de ressource) de BabelOS.
>
>Pour resumer, BabelOS, ca repose sur Babel, et c'est constitue de :
> - classes de services
> - services
> - ressources sous forme d'arborescence avec 3 types de noeuds
> + noeuds terminaux ("vraies" ressources)
> + noeuds non terminaux ("repertoires")
> + renvois ("liens" ~ translators hurd)
en somme ta crainte est au niveau de la representation coherente sous
forme d'arborescence, babelos ne se rapproche-t-il pas d'une sorte de
systeme de fichier virtuelle qui permettrait d'homogeneiser la
representation ?
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 ?)
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.
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.
babelos en soit et une interface qui est instanciee pour referencer
les services (= instances) et ensuite adapater a chaque ressource le
service adapte.
je pense qu'il y a a ce niveau un malentendu, j'entends par la qu'il
faut bien comprendre ce que je voudrais obtenir par mes fichues
instances, elles evitent de se poser trop de question, l'instance doit
manipuler des donnes brutes, elles en ce sens instanciee. l'interface
n'a qu'un seul interet, c'est d'ecrire du code qui peut servir
plusieurs fois (modularite). ensuite, a travers l'instance, on doit
toujours pouvoir invoquer :
instance->methodes(identifiant);
l'identifiant permet de retrouver un element (ce que j'appelle plus
haut pas joliment ressource) dans l'ensemble des donnees brutes que
l'instance est supposee manipuler.
>Pour que les classes de services soient manipulables simplement, il
>faut qu'on ait dans Babel la propriete "une classe est un objet". A
>la maniere de Java. Sinon, on va etre oblige de definir une classe
>de services comme etant une instance d'une interface "classe de
>services". Or, le but ultime serait d'avoir la propriete "service
>est une instance de classe de services". Ce qui n'est pas possible
>avec l'infrastructure Babel de base : une instance ne peut pas etre
>l'instance d'une autre instance. Il va falloir reflechir a ca pour
>Babel.
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).
>Je pense qu'il est necessaire de s'orienter vers BabelOS :
> - Babel + propriete "une interface est une instance de qqch"
> - BabelOS : 2 types : classes de services/services + arborescence
> - de
> ressources
je crois que sur un point tu as raison, actuellement babel souffre de
nombreuses faiblesses :
- probleme d'heritage clair liee a l'idee des dependances entre
instance comme j'en parle juste au dessus
- 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)
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).
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.
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.
je n'ai pas encore trouve un moyen d'arborescencer de facon
satisfaisante, en pouvant exploiter les differents types dont tu
parles et qui sont effectivement indispensables :
> + noeuds terminaux ("vraies" ressources)
> + noeuds non terminaux ("repertoires")
> + renvois ("liens" ~ translators hurd)
mais tu l'auras compris je veut autre chose que ce que je crois qu'on
appelle un vfs.
voila pour le moment.
Julien
ps.
j'ai commence a lire les messages qui suivent... un peu de temps
juste.