BabelOS (was Re: [Kos-dev] developpement de babel... abstraction (suite))

[Fabrice Gautier]

On Fri, 13 Jul 2001 19:58:25 +0200
Julien Munier <munier@wanadoo.fr> wrote:
> 
> 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.
> 

Moi je voyais plutot ca comme ca:

1/ Une interface Filesystem *definit* la methode write

2/ Des "classes" ext2, vfat, etc..., implémente cette interface
Filesystem.

3/ Des instances de ces classes sont atachées à des partitions.

Eventuellement on peut avoir une interface ext2 qui hérite de
l'interface filesystem exportant ainsi des fonctions spécifiques à ext2
(si il ya lieu) et on peut eventuellement avoir plusieurs classes qui
implémente cette interface ext2. 

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

Evidemment les détails dépende de l'implémentation mais en gros quand il
a ouvert le fichier, il a fait un lookup à partir du nom de fichier pour
savoir a quel point de montage le fichier correspond. Il récupère une
structure qui contient les méthodes read/write/etc.. qui correspondent
au filesystem, qui est ensuite accessible a partir du handle de fichier.

Mias la détermination du type de file system est effectué à lors de
lopen pas à read. Ensuite on manipule un "objet" fichier (sous forme
d'un handle qu'on passe a read), le noyau gérant la liste des fichiers
ouverts et faisant la relation entre la handle et la structure qui
contient des pointeurs vers la méthode read correspondante.

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

La je comprend pas très bien. Si moi je fais open("/bin/truc") puis read avec
babel il faudra bien passer par les même étapes c'est à dire identifier
la partitions qui correspond à bin truc, récuperer l'instance Babel
attaché à cette partition. Ensuite le open cree une instance de l'objet
babel fichier qui contient des methodes read correspondantes.

Est-ce que c'est vraiment différent?
Enfin je crois que ce que tu veux dire c'est que avec Babel le read(file,...)
ferait en CPL3 l'appel vers file->read. alors que Unix le fait en CPL0.

Ca m'amène à vous posez la question de savoir si vous voulez avoir une
interface POSIX dans le noyau ou si pour vous ce n'est qu'un élément
optionnelle qui serait fait par l'intermédiaire d'une librairie.

Visiblement avec ce que je comprend de babel c'est plutot la deuxième
solution. Mais ca me fait poser un certains nombre de questions...

D'abord plus c'est beaucoup plus compliqué que ce que je viens de
décrire vaguement pour Unix, parce qu'il ya généralement une couche de
cache entre les deux et au final quand on accède on fait un read dans un
fichier c'est un read dans le cache et c'est le cache qui s'occupe
d'allez lire sur le disque s'il ya un miss, donc la déterminantion du
filesystem ce fait vraiment profondément dans le kernel.

J'imagine qu'avec Babel, l'appel "direct" que tu décris serait un appel
vers le cache, pas directement vers le filesystem.

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

Si tu as une interface filesystem commune et que les interfaces ext2,vfat
en héritent ca ne pose pas de problème.

> 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 sais pas trop ce que tu entend par "dépend de"  dans ta phrase. Moi
je vois deux facon de dépendre héritage et composition:

exemple en pseudo idl/java

interface disque{
	int read_sector(secteur, buffer);
}

class ide implement disque{
	int read_sector(secteur, buffer){
		....
		code qui copie le secteur dans le buffer
		...
	}
	
	private int scsi_disque_number;
}

interface filesystem{
	int read(filename, buffer);
}

class ext2_Impl implement filesystem{
	private disque disque_associé;
	int read(filename, buffer){
		...
		code qui trouve le secteur que l'on veut lire
		...
		disque->read_sector(...);
	}
}

Donc la on a la classe ext2_impl qui implémente l'interface filesystem,
et qui comporte un membre disque_associé qui implémente l'interface disque.


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

Quand tu dis tout je pense que tu veux dire: "toutes les instances" ?

la question est à quoi servira cette représentation? 


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

Je saisis pas vraiment l'intéret en fait. A part faire le préhandler en
CPL3 au lieu de CPL0.
 
> 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 crois pas que tu puisses t'en passer à un moemnt ou un autre, et je
vois pas vraiment quelles avantages tu veux en tirer.

-- 
Fabrice Gautier <gautier@email.enstfr>