[Kos-dev] Deux visions differentes de Babel

[d2]

Bonjour,

Juste une petite chose. D'abord sur l'"elegance" relative des 2
approches. Pour moi, l'approche elegante, la vraie, celle qui est
generale, est bien celle qui consiste a dire que le noyau utilise
Babel, parce que c'est generique et tout : le noyau ne maintient pas
d'interfaces propres pour disk/part et net. Par contre, ce qui me
deplait la-dedans est que le noyau est beaucoup eloigne des entites
bas-niveau qui lui sont tres tres tres tres intimes (pour moi c'est
surtout swap qui est intime, et peut-etre net aussi pour des histoires
de perfs) : y'a Babel entre les 2.

Le cheminement des 2 approches est le suivant :
 + Approche 1/ "Noyau utilise Babel"
     cpl0 : noyau   -> (babel -> objet babel)
     cpl3 : syscall -> (babel -> objet babel)
 + Approche 2/ "Noyau utilise directement ses propres interfaces"
     cpl0 : noyau   -> interface (noyau)  de periph
         ---> 2 (voire 3, cf fin) types seulement de periphs que le
              noyau doit connaitre, avec une interface fixe :
              disk_service et net, ou disk_service rassemble la liste
              des disques et des partitions enregistres a l'init des
              modules ide/scsi/... Et encore, l'important dans
              l'histoire c'est plutot seulement les partitions (les
              disques, le noyau il s'en fout pour son usage intime :
              il n'a besoin de connaitre que les partitions ou il peut
              swapper).
         p.ex : Si on veut pouvoir swapper sur une carte son, ou
         balancer des trames ip sur une carte son, il suffit que le
         driver carte son enregistre un objet partition dans
         disk_service (resp. net).
     cpl3 : 

         Pour /dev/disk ou /dev/part et net :
             syscall -> (babel -> wrapper babel periph noyau)
         Pour le reste :
             syscall -> (babel -> objet babel enregistre par un driver
                         et inconnu du noyau)

   Dans cette approche 2/, si on veut que le noyau swappe sur un truc
   qui ne s'est pas a priori enregistre comme etant (par exemple) une
   partition noyau par son driver de base (mettons : carte tuner TV),
   il suffit que j'enregistre une partition babel_partition qui est un
   wrapper vers babel, et que je fasse en sorte que ce babel_partition
   s'occupe d'appeler le babel de tuner TV afin d'emuler l'interface
   partition du noyau.

Pour resumer, l'approche 2/ est moins "elegante", mais a l'avantage de
maintenir ce qui doit etre intime au noyau, le plus proche possible du
noyau, en evitant les pb de synchro, les lookup, ... le plus
possible. Et peut-etre aussi un pb d'oeuf et de poule qd la memoire
est limite (pas sur). Evidemment, il faut creer un babel pour
disk_service pour que l'utilisateur cpl3 puisse jouer avec des
partitions. Mais c'est pas vraiment une dupplication de code (vu qu'on
ne reecrit pas les drivers disque). Et puis d'autre part, ca n'empeche
pas que le noyau peut quand meme utiliser des trucs exotiques babel
(carte tuner TV par exemple) pour swapper des trucs dessus ou faire du
reseau (moyennant le codage d'un wrapper noyau -> l'objet babel).

Revoir quand meme la liste des trucs qui sont "intimes" au noyau. Je
pense a partition (ou disques, je sais pas[1]) et a net, mais je pense
qu'il y a aussi console. Le reste (son, video, serial, ...), je pense
pas que ce soit critique si le noyau est oblige de passer par Babel
pour que le noyau puisse swapper/faire du reseau dessus.

Voila pour quelques precisions.

Bonne journee,

Notes :
  [1] A mon avis, "disque" et "partition" sont suffisamment proches
      pour qu'ils aient la meme interface (memes methodes), avec juste
      une methode qui indique si l'objet est de type disque, ou
      partition (+ le type de partition). Mais pas sur que le noyau
      ait vraiment besoin de savoir gerer des disques pour son usage
      personnel (swap). Si un disque n'est pas partitionne, on ne
      declare alors qu'une seule partition sur le disque.

-- 
d2