[Kos-dev] Questions et autres problemes philosophiques

[Julien Munier]

Bonjour,

hier soir, je me demandais comment j'allais faire progresser babel,
j'imaginais le resultat du "dev filesystem", je repensais a
l'expression "tout est fichier" et je me demandais ce qu'etait
exactement un syscall sous linux.

voila pour la conjecture du moment :-)


plus serieusement, vous saviez vous que (sauf mauvaise comprenhension
de ma part) "open" est un et un seul appel system, c'est le meme
quelque soit ce que vous openez ?

enfin, bon, tout ca pour dire que en travaillant sur babel, j'ai
essaye de ne pas trop me documenter pour trouver un truc par moi meme
(en verite je savais pas koa lire et j'avais la flemme d'avaler des
tonnes de documents sur la question).

le resultat et que cela ne fonctionnera pas du tout ainsi. 

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

filename    rights    major minor user group
/dev/aaabbc rwxrwxrwx M     m     sys  sys

aaa est l'identifiant de "famille" (a definir encore ce concept)
bb  est un identifiant complementaire (idem)
c   une valeur numerique

M est une valeur Hexa precisant l'instance babel.  
m est une valeur Hexa precisant l'instance symbolisee par ce noeud.


et lorsque je fais un appel systeme :

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

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


De la plusieurs questions :

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

- dans cette perspective quelle doivent etre les fonctionnalites
  implementee par babel ? 

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

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

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


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


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



Juste comme ca...


Julien


PS: promis je serai plus clair a paques :-)