[Kos-dev] Concept de "controleur" ?

Tue, 22 Apr 2003 11:32:01 +0200

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig84F8C74A9EF42E3E853CA04B
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Hello,

[ Beaucoup de gens sur cette liste risquent de trouver ce message
bizarre, parce qu'il parle de choses qui sont en réfléxion entre David,
Julien et moi-même, et nos discussions n'ont malheureusement pas eu lieu
sur la mailing list : nous avons pris la mauvaise habitude de ne plus
l'utiliser. ]

Je vais tout de même tacher d'exposer brièvement le problème. Nous avons
introduit dans KOS l'idée que l'on ouvrait une "ressource" selon une
"interface".

Sous Unix, lorsque que l'on appelle open() sur un objet de l'espace de
nommage, il est entendu implicitement qu'on souhaite ouvrir cet objet
selon une interface de type "fichier", puisque sous Unix, tout est
fichier. Cela a l'avantage de l'uniformité, mais comme chacun le sait,
cela entraîne aussi l'existence du magnifique appel ioctl() pour gérer
les choses bizarres.

Sous KOS, l'idée est que l'on peut ouvrir une ressource (un object de
l'espace de nommage) selon une interface donnée. On pourra par exemple
ouvrir /home/ selon l'interface INTERFACE_DIR, /home/thomas/toto selon
l'interface INTERFACE_FILE, /dev/dsp selon l'interface INTERFACE_FILE ou
INTERFACE_SOUND par exemple. Tout cela semble fort pratique, simple et
évolutif.

Malheureusement, en interne, un problème se pose en ce qui concerne
l'implémentation des drivers et la factorisation du code.

En effet, chaque driver va implémenter des fonctions correspondant aux
méthodes des différentes interfaces que le driver souhaite exporter pour
les différents objets de l'espace de nommage qu'il gère. Pour chacune de
ces méthodes, il existe au niveau utilisateur (en CPL3) un petit bout de
code qui va permettre d'aller appeler la méthode correspondante dans le
noyau, via un syscall. Lorsque l'on va appeler dans un programme
utilisateur la méthode set_volume() de l'interface INTERFACE_SOUND sur
l'objet /dev/dsp, on va directement se retrouver dans le noyau dans le
code de la methode set_volume() du driver chbouibMachinChose qui gère la
carte son en question. C'est ce qui est attendu.

Par contre, dans le cas des périphériques blocks, on ne souhaite pas que
l'appel a la méthode read() de l'interface INTERFACE_BLOCK atterrisse
directement dans le coeur du driver de disque dur : le driver de disque
dur ne sait que lire et écrire par blocs, alors qu'on veut y ecrire et
lire octet par octet (comme dans un fichier). Ce boulot de
"fragmentation/defragmentation" echoit (conjugaison douteuse ?)
normalement au cache, mais ici, point de cache : on atterit directement
dans le driver, pas de couches intermédiaires, pas de possibilité de
factoriser le code. Dans le cas de certaines interfaces, cela pose un
réel problème.

Pour information, Hurd fonctionne un peu comme nous, avec des interfaces
spécialisées. Pour la gestion du cache et le problème des blocks
devices, ils ont trouvé une solution : ils mappent en entier la
partition dans l'espace d'adressage. On peut donc y accéder octet par
octet (c'est de la mémoire), mais les accès se font bloc par bloc (page
par page plus précisement). Cela est possible dans le Hurd car le
translator ext2fs, qui permet de monter la partition est un processus
utilisateur séparé, ce qui n'est pas le cas dans KOS.

Dans KOS, il faut trouver une solution différente pour factoriser ce
code. L'idée la plus simple qu'il me vient à l'esprit est une sorte de
"controleur" : pour chaque interface, il y a un controleur a qui on
passe un identifiant de driver et qui propose toutes les méthodes de
l'interface. Dans le cas de block, la fonction read() du controleur
gérerait le cache, les problèmes de fragmentation/défragmentation, etc..
 en s'appuyant sur la méthode read() du driver passé en paramètre.

De toute façon c'est une idée un peu comme celle-ci qu'il faut (je
pense) utiliser. La question maintenant est : est-ce que ce problème de
factorisation de code est inhérent à block et à ce moment là il faut
trouver une solution spécifique à block, ou alors est-ce que ce problème
risque de revenir avec de nombreuses interfaces, auquel cas il faut
trouver une solution globale pour le système.

Voilà le fruit de mes réflexions. J'espère réellement qu'on trouvera une
issue à ce problème, car j'attends les solutions pour pouvoir me lâcher
sur le codage ;-)

Bonne journée,

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni@enix.org - UIN : 34937744
Web: http://www.enix.org/~thomas/
KOS: http://kos.enix.org/ - Lolut: http://lolut.utbm.info
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7

--------------enig84F8C74A9EF42E3E853CA04B
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+pQwR9lPLMJjT96cRAvqMAJ499T5FKshlYVjXckreK/MzGZZfGACfZm9X
OvijtKnPHh/XntIJNq52Qow=
=G7o3
-----END PGP SIGNATURE-----

--------------enig84F8C74A9EF42E3E853CA04B--