[Kos-dev] Reflexions...

[Thomas Petazzoni]

Bonjour,

Durant mes quelques jours de simili vacances, j'ai continue a reflechir
a KOS, et notamment aux problemes d'interfacage avec le CPL3 dont nous
avions parle dans plusieurs mails.

Au final, j'ai ete amene a me demander si la voie que nous avions pris
avec Babel n'etais pas incoherente sur certains points. En effet cette
histoire de translator/shadow_resource fait que les fichiers de /dev
sont un peu speciaux, alors qu'en fait c'est rien de moins que des
fichiers, tout comme /home/thomas/foo/bar. J'explique mon probleme :

on veut renommer /home/thomas/foo/bar. On a la resource correspondant a
ce fichier, donc la shadow resource, et enfin le translator (aka
l'instance du systeme de fichier qui gere cette resource). On peut donc
aisement lui demander de renommer ce fichier.

on veut renommer /dev/sound/dsp en /dev/sound/macartesondelamortkitue
(pourquoi pas ?). On a la resource correspondant a /dev/sound/dsp. On a
la shadow resource. Mais la le translator correspondant c'est pas DEVFS
(qui pourtant est le systeme de fichiers permettant de renommer ce
fichier), mais c'est directement une instance de l'interface sb16 (par
exemple).

Et ce probleme de concerne pas uniquement devfs, on pourrait imaginer
avoir un teamfs (chaque team est un repertoire, avec un fichier de
description + un fichier pour chaque thread), on pourrait imaginer avoir
un semfs, un pipefs, un procfs, enfin bref, plein de trucs louches.

Je me demande si finalement on devrait pas repenser la chose autour du
concept Unix de fichier, mais en le pensant oriente objet.

public class file {
 public int read();
 public int write();
 public int seek();
 public int rename();
 ...
}

public class harddisk extends file {
 public int format();
 public int read_partition_table();
 ...
}

Etc...

Honnetement, je ne sais pas du tout si ca peut marcher si ca convient,
etc.. mais il me semble que le modele actuel de Babel est un peu bancal.
Nous l'avons trop pense dans la restriction : on a des fichiers normaux
geres par une partition et des fichiers bizarres dans /dev.

Une autre idee : tout baser autour de protocoles :
 dev://disk/hda (protocole dev)
 file://home/thomas (protocole file)
 http://kos.enix.org/ (protocole http)
 team://1962 (protocole team -> acceder aux infos sur la team 1962)
 pipe://mafifo (protocole pipe)
 ...

Voila, je vous livre, comme ca un peu decousues mes reflexions de ces
derniers jours. L'idee du modele objet a partir de file c'est que notre
couche d'emulation Unix ne saurait utiliser que la classe de base file
(definie plus haut). La libc, en plus d'avoir des fonctions haut niveau
genre printf, scanf, etc..., serait un wrapper C -> notre modele oriente
objet limite a la classe file.

En ce qui concerne les programmes qui font des trucs louches (formatage
de disque, trucs bizarres avec les cartes graphiques, etc...) ->
obligation d'utiliser le modele oriente objet. De toute facon, quand tu
fais un truc louche avec une carte son, t'es oblige de savoir que c'est
une carte son non ?

Les deux idees a la base de ma reflexion c'etait d'essayer de penser
Babel encore plus oriente objet, tout en essayant de coller au concept
de fichier et de partir d'une classe "file" de base afin d'assurer une
compatibilité Unix via la libc.

A developper. Reactions/remarques/questions/reponses/idees/reflexions
bienvenues.

Sinon en ce qui concerne mon projet d'UV (realisation fork() + exit())
je crois que je vais laisser tomber : pas assez de temps, et surtout
pour l'instant notre systeme de communication CPL3 -> CPL0 est assez
flou...

Bonne journee,

Thomas
--
PETAZZONI Thomas - icq #34937744
thomas.petazzoni@enix.org - http://www.enix.org/~thomas/
Projet KOS : http://kos.enix.org
Club LinUT : http://club-linut.enix.org