[Kos-dev] Progressions du WE

Thomas Petazzoni kos-dev@enix.org
Mon, 15 Oct 2001 16:36:19 +0200


salut,

ce WE, je suis alle chez Julien a Lyon, et nous avons pu discuter de
Babel, du langage a definir, et de l'interaction entre VMM.

WE 12-14 Octobre 2001

VMM, shadow resources, et resources
-----------------------------------

Les shadow resources sont intimement liees a la VMM, c'est donc ce
module qui s'occuper de maintenir l'ensemble des shadow resources, si
possible sous la forme d'une table de hachage, indexee par nom (la
chaine de caracteres utilisee pour representer l'entite dans l'espace
de nommage). Cette table de hachage permettra au
createur/desctructeur/collecteur de ressources, implemente en temps
que sous ensemble de Babel de savoir si une shadow resource existe
deja ou non pour la ressource à créer. 
Pour résumer :
        Shadow resource => VMM
        Resource        => Babel
Il est clair que la seule facon d'identifier une shadow resource est
la chaine de caractere la representant dans l'espace de
nommage. Toutefois, afin d'accelerer les recherches dans la liste de
ces shadow resources, l'utilisation d'une table de hachage est
fortement souhaitable.

Les drivers de virtual region, de type _vmm_zero, _vmm_kmem et
_vmm_kstack seront implementes dans le module VMM, et une sorte de
glue permettra de les representer dans l'espace de nommage en cpl3.

D'autre part, une fonctionnalite devra etre ajoutee a Babel,
permettant de limiter le nombre d'instanciations d'une interface
donnee. A priori, il n'est pas utile d'instancier plusieurs fois des
interfaces du type "/dev/zero", "/dev/kmem" ou meme
"/dev/kstack".

Actuellement, les drivers de shadow resource imposent l'existence
d'une fonction raw_read et raw_write. Toutefois, ces pointeurs de
fonctions ne sont pas necessaires a ce niveau. En effet, toute shadow
resource comporte un translator vers l'instance a utiliser. Et cette
instance decoule d'une interface, possedant obligatoirement les
methodes raw_read et raw_write si la resource cree est mappable en
memoire.

On peut imaginer une interface virtuelle simple, regroupant l'ensemble
des interfaces virtuelles et des interfaces permettant de manipuler
des objets mappables en memoire (via mmap).

Exemple :
virtual interface memory_mapable extends babel 
{
  methods:
   int raw_read();
   int raw_write();

  private:

  shared:

  resource:
}

Definition du langage 
---------------------

Le langage s'appelle K. Une doc est disponible sur le cvs dans
kos/doc/k. Des exemples de sources sont fournis.

Voila ... suggestions, critiques, idees ?

Amicalement,

thomas
-- 
PETAZZONI Thomas
thomas.petazzoni@meridon.com     UIN : 34937744
Projet KOS : http://kos.enix.org
Page Perso : http://www.enix.org/~thomas/