[Kos-dev] Questions et autres problemes philosophiques

[d2]

[ Il faudrait changer le reply-to -> kos-dev@enix.org, sinon bounce ]

>>>>> "Julien" == Julien Munier <munier@wanadoo.fr> writes:
    Julien> plus serieusement, vous saviez vous que (sauf mauvaise
    Julien> comprenhension de ma part) "open" est un et un seul appel
    Julien> system, c'est le meme quelque soit ce que vous openez ?

Oui. Je pense que c'est un but fondamental de l'OS : abstraire les
ressources materielles, et pouvoir y acceder a peu pres
uniformement. En consequence de quoi l'utilisateur manipule de la meme
facon (meme appel systeme) un fichier, une partition, ...

    Julien> en fait au niveau du dev-fs, il sera tenu a jour par le
    Julien> noyau (pour simplifier on va dire ca comme ca). on aurait
    Julien> alors par exemple un noeud :

Alors babel serait un devfs ?

    Julien> sycall(M, m, "Id du service connu par stubs", args);

    Julien> alors babel va rechercher le service (fonction
    Julien> lookup_service) appel le service avec les arguments et
    Julien> renvoie le resultat.

Si je me limite a ca, Babel va plus loin que devfs, et je suis rassure.

    Julien> - craigniez vous un manque d'homogeneite dans les appels
    Julien> systemes, personnellement je n'y crois pas car on connait
    Julien> les interface des instances avec lesquelles on travaille
    Julien> et donc les methodes auxquelles on peut acceder, ensuite a
    Julien> charge des developpeurs de conserver des noms de methods
    Julien> homonymes voire standardisees pour plus de clarte

Ca, c'est le boulot du generateur de stubs (appelons-le C--). Je
m'esplique : pour ce qui est de l'hommogeneite, c'est assure a partir
du moment ou on a une notion d'heritage entre les services (a vue de
nez : l'heritage mene a l'homogeneite via le polymorphisme). Va
falloir que d'une maniere ou d'une autre la description en C-- repose
sur une notion d'heritage. Babel en lui-meme (ton API C) n'a pas
besoin d'etre conscient de cet heritage, je pense.

    Julien>   je m'explique, par exemple, un driver clavier pourrait
    Julien> aparaitre dans /dev/kbd-0 et un driver ecran
    Julien> /dev/screen-0, alors ce ne serait pas au noyau de proposer
    Julien> des /dev/tty ou /dev/console puisque cela suppose une
    Julien> gestion par le noyau de l'association clavier/ecran ?

Pas possible ? Pour moi, un tty est une abstraction de niveau
superieur a laquelle serait associe un peripherique d'entree (clavier,
plus generalement flux in), et un peripherique de sortie (ecran, plus
generalement flux out). En modelisation objet, on aurait la relation
"tty possede un flux IN *et* possede un flux OUT", et on a les
relations "un Ecran est un flux OUT" et "Un clavier est un flux IN"
(heritage).

Le probleme d'Unix, c'est qu'on n'a pas d'heritage, puisqu'on n'a
qu'une seule classe : FileDescriptor. Et donc on ne voit pas bien
toute la demarche precedente.

Si on veut gerer des interfaces plus variees, alors on va avoir besoin
d'une notion d'heritage ET (surtout) de polymorphisme. Sinon, comme tu
le dis, on va etre coince, parce que le noyau en lui-meme ne pourra
pas tolerer d'avoir un tty qui puisse etre une association "abstraite"
FluxIn/FluxOut.

Il va donc falloir potasser au moins le polymorphisme au niveau de
Babel (C), et l'heritage au niveau C--.

    Julien>   ensuite supposons qu'on ait un /dev/scsi-hd-0 avec des
    Julien> methodes pour lire physiquement le disque scsi 0 mais il
    Julien> faut un systeme de fichier derriere donc il faut quelque
    Julien> part une "libraire" par exemple libext2. La question est
    Julien> alors ou est code la librairie ?  dans le noyau ou par une
    Julien> lib CPL3 qui va se charger de travailler avec
    Julien> /dev/scsi-hd-0 ? de meme pour les drivers rezo, est ce que
    Julien> c'est au noyau de fournir un driver TCP/IP ? NFS et
    Julien> touttiquanti ?

Si tu veux une lib linkee avec le code cpl3 pour la gestion FS par
exemple, fais un tour du cote de exokernel, qui porte decidement bien
son nom. C'est vrai qu'on gagne en rapidite d'acces. Mais ca doit
faire goulot d'etrangelement des qu'il y a plusieurs processus qui
lisent/ecrivent sur le meme FS. Dans un OS "normal", on peut se
permettre de centraliser un cache et un "elevator" qui va optimiser
l'acces au physique en cas de contention ; je ne pense pas
qu'exokernel s'occupe de ca : les processus fonctionnent en egoistes
avec le matos. Bref, comme d'hab, tout depend de l'utilisation : OS
generaliste/specialise, beaucoup d'acces au hard concurrents/peu de
contention...

L'autre solution, c'est l'approche µ-noyau. La, les services de plus
haut niveau (=> pas la gestion niveau matos) sont deportes dans des
satellites (serveurs) qui sont proteges par rapport au cpl3 (mais pas
forcement en cpl0). On peut a ce titre deporter la gestion des FS dans
des serveurs a part.

Sinon, pour le reste, il y a l'approche monolythique (tout cpl0, sauf
les utilisateurs).

Honnetemenent, pour moi, le cpl3 ne doit pas s'occuper du FS. Donc
c'est dans un noyau ou dans un serveur pour µ-noyau que ca se passe.

    Julien>   je pense que la question est fondamentale, il faudrait
    Julien> se mettre d'accord sur le role du noyau. Avec babel a
    Julien> l'heure actuelle il proposerait *uniquement* de proposer
    Julien> une couche logiciel a ce qui est materiel. a charge des
    Julien> applications du systemes de fournir les couches
    Julien> logicielles complementaires (support de systeme de
    Julien> fichier, protocoles, support de consoles).

On va faire un petit historique : au depart Babel se voulait un
repertoire d'interfaces au sein du noyau, pour abstraire la gestion de
certains matos, a des fins de portabilite. Puis on en est venus a se
dire qu'il serait interessant de pousser cette abstraction un peu plus
loin : au dialogue avec le cpl3, et pour des "services", c'est a dire
pour bien autre-chose que du matos *hard* (dont le cpl3 se soucie peu
en general).

Alors ce que j'en pense, c'est que *si* il s'agit de proposer une
couche d'abstraction *du matos*, alors ca doit rester au sein du
noyau, et ne pas en sortir (on peut se passer d'heritage et de
polymorphisme). Si on voit le cpl3 dans l'affaire, alors il faut aller
plus loin que l'abstraction du matos, et passer a la notion
d'heritage/polymorphisme.

La, il faut maintenant faire un choix.

    Julien>   mon avis sur la question : je trouve l'idee seduisante
    Julien> d'un noyau se contentant de faire ce qu'il est suppose
    Julien> faire je crois : donner une existence logicielle au
    Julien> materielle physique.

Certes, mais ca me parait insuffisant "de nos jours".

    Julien>   evidemment vous allez me dire : comment je fais avec mon
    Julien> noyau pour qu'il invoque un programme si je n'ai pas de
    Julien> libext2 dans mon noyau pour le retrouver sur mon disque ?

Facile, quand on boote, on fournit le programme de demarrage : init +
libext2 (role du processus de chargement du noyau). C'est lui qui va
chercher les autres programmes. Et, par recurrence, quand je fais
"exec truc" depuis un processus, il reprend son libext2 et s'en sert
pour charger "truc", en lui fournissant libext2. A son tour on pourra
faire "exec machin" depuis "truc".

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.

Bonne journee,

-- 
d2