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

[Julien Munier]

Re,

pour le chainage on peut decrire l'ensemble des informations necessaire
en adoptant une syntax particuliere :

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

par exemple "drv(block)|libblockio(file):bs=512"

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.

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 par
exemple) (ie les fonction raw_read et raw_write de l'ide transmis au
libblockio). 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. dans ce cas il faudrait
que la librairie fournisse la liste des interfaces supportees (ce qui
est naturellement la merde) dans la deuxieme considerations (et deja pas
mal dans la premiere) en terme de dynamicite :-(.


si on arrive a contourne ce probleme on peut admettre que les lib (aka
translator dans ce cas) implementent des interfaces et surtout sont
capable de generer des sres (ou ures) a partir d'une sres (ou ures)
issue d'un driver et de ce chainer ainsi en fonction de la demande.

la difference c'est que dans le code on faisait ures_alloc(kr,
interface) dans ce cas, il faut utiliser une fonction de la librairie :
libblockio_ures_alloc(block_ures_driver_ide, conf) par exemple.


a voir,

--
J.