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

[Thomas Petazzoni]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigEE4345AED9174E4440A78FEE
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Hello,

> "(driveroutputinterface)|trans(outputinterface):param=val1, \
> param1=val2|trans2(outputinterface2)"

Bien sur qu'on peut adopter ce genre de syntaxe (assez imbuvable, mais
peu importe). L'idée est qu'on doit pouvoir spécifier les traducteurs
*par* interface, et non pas globalement sur une ressource.

> par ailleurs on peut toujours faire "drv(block)" ou "drv(block_tuning)"
> drv se rapportant au driver courant pour le peripherique ou la resource
> designe en parametre (i.e. "/dev/hda"), non ? explique moi si j'ai pas
> bien compris tes inquietude au des interfaces.

Si tu exprimes le driver *et* l'interface, alors oui, tu peux travailler
de cette manière.

> la ou je vois personnellement une contrainte c'est que dans tes
> librairies, tu vas devoir passer un objet (je j'avais appelle avant
> sres), qui est donc une kres ouverte selon une certaine view (block pa
> exemple)

Pop, pop, pop. L'expression "kres ouverte selon une certaine vue" n'est
pas valide : la kres donne justement la liste de toutes les interfaces
supportées. Elle n'est pas ouverte "selon une vue". Ce sont les ures,
créées lors d'un open "selon une vue" qui sont ouvertes "selon une vue".

> (ie les fonction raw_read et raw_write de l'ide transmis au
> libblockio).

Pas de raw_read, raw_write : il faut une interface block qui permettent
de lire block par block, ou alors si on veut un truc plus souple une
interface kernel_io qui sert au noyau quand il veut faire des I/O (pour
le file mapping notamment).

> et il faudra tester si la sres que tu transmets a un
> interface compatible avec l'interface demande par la librairie. or on
> peut faire deux suppositions : soit un admet que le block et le
> disk_perf_tuning fournissent des methodes completement independantes ou
> bien que disk_perf_tuning est un block custom.

block et disk_perf_tuning sont *completement* differentes.

Et c'est justement ça le problème : il faut pouvoir dire je veux créer
l'interface "file" (et donc son implémentation) à partir de l'interface
"block" de tel objet, géré par un driver. Et on devra avoir l'impression
que cette interface "file" est effectivement exportée par le driver en
question. Et d'autre part, on devra quand même pouvoir accéder à toutes
les autres interfaces de l'objet : block et disk_perf_tuning pour l'exemple.

Bref si on accède via block ou disk_perf_tuning -> il faut aller
directement dans le driver. Si on accède via file -> il faut passer par
un merdier intermédiaire.

Toute la question est : comment accrocher de façon propre ce truc. A mon
avis on peut s'en sortir en faisant la chose suivante dans le driver block.

int ata_init(void) {
  detect_disk();

  if(j'ai trouvé un disque primaire master) {
    allocation de quelque chose pour représenter ce disque
    enregistrement de cet objet dans devfs
    enregistrement de l'interface block pour cet objet dans devfs
    enregistreemnt de l'interface diskperf pour cet objet dans devfs
    création de l'interface file par libblockio
    enregistrement de l'interface file pour cet objet dans devfs
  }
}

Avec cette solution, les fonctions de l'interface "file" sont
directement dans la librairie libblockio, elles seront du genre :

int file_read(struct kres *objet, ...) {
  // Faire du merdier

  kres->block_interface->block_read(objet, ...).

  // Faire du merdier
}

C'est une autre solution que celle proposée. Je ne sais pas si c'est
possible, mais j'en ai l'impression. Perso je voterais plus comme
quelque chose comme ça, parce que l'histoire de la chaine de caractere,
tout ça, ça me plait moyen.

L'idée c'est juste qu'on veut pouvoir créer des interfaces
supplémentaires dans un objet à partir d'interfaces déjà existantes. A
mon avis c'est à l'objet lui même de le faire. Et *toutes* les
interfaces sont quand même exportées par l'objet, même si il dispose
d'une aide pour l'implementation de certaines d'entre elles.

Je suis pas sur d'être clair. Si ce n'est pas le cas, demande moi, je
réexpliquerai ma vision, sans aucun problème.

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni@enix.org - UIN : 34937744
Web: http://www.enix.org/~thomas/
KOS: http://kos.enix.org/ - Lolut: http://lolut.utbm.info
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7

--------------enigEE4345AED9174E4440A78FEE
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+qUKL9lPLMJjT96cRAkywAKChHbM+bhqpSmutZxzjTR9dud/7HACeOsYH
5JZgIeIoq6qrx8NfM5SWqoo=
=1jiQ
-----END PGP SIGNATURE-----

--------------enigEE4345AED9174E4440A78FEE--