[Kos-dev] revoir encore une fois notre copie ?

[Julien Munier]

Salut,

je viens de lire vos interventions et ca fait depuis hier soir que je
repense a ce qu'on a deja pu ecrire, je pense qu'il faut qu'on revoit
encore un truc, en particulier il manque un truc 'achement interessant
: j'appelle ca la serialisation, je me trompe de terme vous me
corrigerez.

en fait il faut qu'on puisse ouvrir une resource d'apres une liste
d'interface a appliquer. des a present je pense qu'il faut ajouter une
chose a nos idees d'interfaces. jusqu'a present on a dit que l'on
definit globalement les interfaces et chaque driver doit implementer
les interfaces qui l'interesse. cependant on se rend compte que ce
modele est insuffisant en effet certaines interfaces sont
device-independant :). elles se rapprochent plus de librairies dans le
noyau par exemple la gestion des partitions ou des caches blocks, ou
de la crypto ou des pseudo-tty par exemple.

donc il faut modifier tout ca. en particulier parce que le
comportements des drivers qui implementent les interfaces et les
librairies qui implementent des interfaces ne fonctionnent pas de la
meme maniere.

d'ou le concept de serialization.

en fait il faut qu'on puisse ouvrire un objet par exemple admettons
que le driver ide lors de l'init enregistre dans le devfs le
peripherique /dev/hda. et qu'on veut cree les noeuds des partitions.

on a donc une libraires part mais aussi on admet que /dev/hda
implemente l'interface block et qu'on a aussi une libraire
libblockcache.

alors on peut ouvrir :
      rd = open("/dev/hda","block|libblockcache:bs=512|part");
      OPS(rd)->makedev(); /** genere les /dev/hda* */
      OPS(rd)->close();

donc il faut transmettre une structure de donnees qui decrive les
differentes interfaces et leur parametres de configuration lors de
l'appel open.

peut-etre quelque chose comme :

struct serialize_config {
 unsigned nb_level;
 struct level_config {
   unsigned interface_id;
   unsigned nb_param;
   struct interface_config {
     const char *param;
     const char *value;
   } **param;
 } **level; 
};

a ce moment la dans le code du open il faudra changer des trucs : en
effet la serialisation implique que le noyau manipuler des ures or on
veut que les ures soient juste pour le nivau utilisateur donc il peut
etre utile d'utiliser une autre structure : sres pour serialized
resource en somme.

la structure de sres est une forme canonique de la structure de ures
en fait. mais c'est une question de principe en fait.

donc lorsque tu crees un serialized resources, tu dois utiliser une
fonctions serialize a qui tu donnes la kres de base (i.e. /dev/hda)
puis la structure de config. cette fonction va creer les sres qui vont
bien en appelant la librairie associe a l'interface_id de chaque
niveau. les librairies devront donc prendre la sres de la couche
inferieure en parametre et fournir une sres pour leur level avec les
parametres qui vont bien (rem. y'a de gros testes a faire pour
verifier que la sres qu'on transmet est reellement utilisable par la
librairie), etc ... jusqu'au dernier level ou on construit ensuite une
ures.

ainsi une fois qu'on a implementer la serialisation, tous les
problemes de factorisations de code seront gere de facto.

a vos commentaires, pret, partez !

--
Julien


ps. je vais essaye de code un peu ce modele pour voir ou ca bloque,
paske je sens que c'est a peine chiant a faire ;-)