[Kos-dev] Questions et autres problemes philosophiques

Julien Munier kos-dev@enix.org
Sat, 24 Mar 2001 10:59:12 +0100


Salut,

  >Alors babel serait un devfs ?
  >Si je me limite a ca, Babel va plus loin que devfs, et je suis rassure.

non, ni l'un ni l'autre : babel en lui meme ne sert qu'a faire ce
qu'il fait actuellement cad enregistrer/supprimer des interfaces et
creer et detruire des instances.

et pour repondre a ton historique sur babel, je pense qu'il faudra
s'en tenir la, pour les autres morceaux on pourra trouver pleins
d'autres zolis noms pour les designer.

ensuite, je songe a un *service* qui pourrait se charger de maintenir
un devfs, de meme, je pense que c'est un autre module qui s'occupera
du syscall (j'ai commence a ecrire un modules syscall qui fonctionne
*avec* babel, mais ca ne me plait pas et le fonctionnement des
syscalls m'est encore quelque peu obscur).

Sinon, j'ai reflechi un peu a ce probleme de niveau d'abstraction.  Je
ne pense pas que ce soit au noyau de fournir des abstration aussi
poussee que des terminaux par exemple, mais je ne pense pas non plus
que cela doivent etre des "vulgaires" libraries utilisateurs. J'adpote
donc la terminologie de serveur (attention, j'utilise ce mot parce que
tu l'as propose et non parce qu'il doit decrire un fonctionnement deja
connu au niveau des micro-noyau - que je connais tres mal).

Ainsi, je pense que le noyau, pourrait se contenter de donner une
existence logiciel aux composants materiels et fournir une gestion
logiciels des domaines tres sensibles que sont le scheduling, la
memoire, et les ipcs.

Ensuite on peut laisser a charger de serveurs les domaines de plus
haut-niveau.

Ainsi, on peut imaginer (toujours en gardant a l'esprit ce devfs avec
un noeud sur une instance gestionnaire d'un clavier et une instance
gestionnaire d'une sortie type ecran), un serveur qui permettrait de
construire des terminaux.

on lui dirait alors :

$ serveur -tty /dev/ttyp -number 10 -in /dev/clavier -out /dev/ecran
(rem : p pour pseudo)

on peut alors imaginer des noeuds apparaitres : /dev/ttyp0 /dev/ttyp1
... /dev/ttyp9

un autre interet de ce systeme que je vois la, c'est simplement pour
la gestion des disques durs : devfs nous propose /dev/disk0partition0
alors on peut invoquer un serveur qui pourrait "mounter" le disque :

$ serveur -mount /mnt -disk /dev/disk0partition0 -fs ext2

L'avantage et que les appels a ces "peripheriques de haut niveau" ne
se feraient pas via syscall dans un premier temps, le serveur pourrait
comme le noyau le ferait, bufferiser les acces. et on pourrait rester
alors performant ?!

Une autre originalite a terme pourrait etre d'associer a un
peripherique donne, un driver qui se situerait sur une autre machine
(et inversement ?), voir meme installer un peripherique et un
peripherique situe sur une machine distante (NFS !).

$ serveur -mount /mnt -disk 182.234.543:/dev/disk0partition1 -fs
182.234.234.543:/libfs/ext2fs.a

bon, j'avoue la c'est limite fantaisiste :-)

Neanmoins d'un point de vue esthetique une question se pose, les
noeuds que creerait un serveur serait une especes evoluee des noeuds
generes par un hypothetiques devfs ? comment les gerer ? a voir, c'est
a dire que par exemple un serveur gerant un disque pourrait mounter
directement le disque sur l'arborescence, pour un terminaux c'est
moins evident, peut-etre faut-il continuer a placer ces fichiers dans
un /dev mais la j'avoue que c'est de l'ordre du detail, bien que
l'esthetique soit importante pour que l'utilisateur final ne s'y perde
pas trop.

  >Jetez un oeil a ca : http://freshmeat.net/articles/view/237/ . C'est
  >joli tout plein, mais un peu fumeux. C'est pas ininteressant quand meme.

surtout fumeux qd meme :-)

a plus,

Julien