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

[Thomas Petazzoni]

bonjour,

ce mail est plus particulierement destine a julien, mais toutes les
suggestions sont attendues.

Sous Unix, on considere que "tout est fichier". Cette abstraction est
pour l'instant celle qui me parait la meilleure, en effet on peut
representer un fichier par un fichier, un peripherique par un fichier...

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

Un ami de D2 nous proposait durant le LSM l'abstraction "tout est
socket". C'est une autre solution effectivement, mais la aussi il est
assez difficile de considerer un fichier comme une socket. Cependant on
pourrait imaginer
	- connect correspond au open
	- send correspond au write
	- recv correspond au read
	- disconnect correspond au close.
Est-ce que cette abstraction est interessante ? Surement que oui, comme
toute abstraction, elle a ses avantages, et ses inconvenients.
Est-elle en accord avec l'idee de Babel ? Je ne pense pas.

Personnellement voici ma vision des choses : tout est fichier. Avec
Babel, c'est ce qu'il y a de plus simple, de plus evident de plus clair.

La libc ne fait que des open/read/write/close/etc... sur des noeuds dans
un systeme de fichier virtuel. Babel determine si le noeud a acceder est
un vrai fichier ou non. Si c'est un vrai fichier, alors il utilise le
module correspond au systeme de fichier. Si c'est un pseudo fichier
(peripherique), il appelle le module correspondant a ce fichier. Enfin
ce role peut aussi revenir a la libc, c'est discutable. Ce que je
voulais simplement montrer c'est que l'abstraction "tout est fichier"
est la plus pratique et la plus claire du point de vue utilisateur.
Toutefois cela n'empeche pas de voir Babel comme un gestionnaire
d'objets, et qu'au sein du noyau l'abstraction de base soit l'objet.

L'abstraction tout est fichier est interessante pour une autre raison :
le type de segment de memoire virtuelle SEG_VNODE peut etre utilise a la
fois pour mapper des fichiers en memoire (mapper une section de code, de
donnees, ou alors mmap()), pour mapper des zones de pages anonymes (qui
ne correspondent pas a un vrai fichier, mais a quelque chose comme
/dev/zero), et pour mapper des peripheriques (ex : /dev/fb0 pour un
framebuffer).

Bref l'abstraction tout est fichier, meme si elle n'est pas
revolutionnaire est celle qui me convient le mieux. Je voulais attirer
votre attention sur ce sujet, car il devient vraiment urgent de savoir
vers quelle abstraction nous voulons nous diriger car cette decision
conditionne pas mal du boulot a venir dans KOS, notamment la memoire
virtuelle, sur laquelle je compte bien travailler activement dans les
jours qui viennent.

Amicalement,

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