[Kos-dev] Deux questions sans reponses

[Julien Munier]

salut,

a propos de :

  >>         2. Comment vont se gerer les stubs au niveau CPL3 ? Il
  >> faudrait pas qu'on ai besoin de recompiler la libc a chaque fois qu'on
  >> ajoute une fonctionnalite dans le systeme. Pour un OS qui se veut
  >> dynamique, ca serait un peu pourri !
  >
  >Mais bon ca t'oblige pas forcément a recompiler une libC, juste t'as
  >libc aura pas tout les syscalls de ton kernel. C'est exactement pareil
  >pour linux aujordh'ui, quand unsyscall est rajouté si la libc ne le
  >supporte pas, t'es obligé de faire des contorsions pour l'appeler.
  >
  >De toute facon une fois que les interfaces de BabelOS sont définis, ca ne
  >devra pas forcément bouger tant que ca.
  >
  >D'aileur il est pas frocément dit que ce soit la libc qui contiennent
  >tous ces appels directs vers les drivers. Une libbabel/libbabelos serait
  >sans doute plus adapté si tu limites la libC aux fonctions définies par
  >le standard et aux fonctions POSIX.

oui, est en particulier, dans notre esprit modulaire, il me semble
interessant d'exploiter le principe de librairies partagees, il suffit
de disposer d'une librairies modules d'une libBabel.

en fait j'imaginais, que pour toute interface dans le noyau, la chose
se presenterait sous la forme suivante :

on presente la chose sous l'appellation "kernel package" format
".kpkg" par exemple, dedans tu a un ".ro" que tu exploites par une
commande similaire a insmod sous linux, il y aura le code pour le
noyau comme nos modules du loader actuel d'ailleurs. par ailleurs tu
as les includes ".h" pour pouvoir manipuler les methodes des instances
qui dependront de l'interface et finalement une librairies ".so" qui
implemente le code pour le lien CPL0/CPL3.

pour exemple :

babel.kpkg
 ( 
   - babel.ro
   - include/babel.h
   - babel.so 
 )



Julien