[Kos-dev] Libblockio

[kos-dev@enix.org]

>De: Thomas Petazzoni <thomas.petazzoni=40enix.org>
>
>Hello,

Salut,


>En ce qui concerne les probl=E8mes sp=E9cifiques li=E9s aux block devices=
,
>voici comment j'ai d=E9cid=E9 de r=E9gler le probl=E8me, tout du moins
>temporairement, on verra ce que =E7a donne =E0 l'impl=E9mentation et dans=
 le
>futur. Il faut qu'on arr=EAte de concevoir, et qu'on code ;) Si c'est pas
>beau, on refera, mais en tirant enseignement des erreurs, et en
>augmentant petit =E0 petit la difficult=E9 du probl=E8me.
>
>Je propose de cr=E9er une librairie libblockstore ou libblockio (enfin pe=
u
>importe j'ai toujours =E9t=E9 mauvais pour le nommage). En gros, cette
>librairie permet de transformer des requ=EAtes byte-aligned en requ=EAte
>block-aligned.

Je verait plutot une libkio plus generique qui gererait tous sorte d'acces=
 par io (et ne pas se limiter au acces par blocks, certains periphs consid=
eres par blocs ne fonctionnent qu'en raw commes d'autres que par requetes =
a la granularite fichiers).

>Ensuite, on proc=E9dera de la sorte dans le driver disk :
>
>block=5Finterface=5Ft block=5Finterface =3D =7B block=5Fread, block=5Fwri=
te =7D;
>file=5Finterface=5Ft file=5Finterface =3D =7B file=5Fread, file=5Fwrite =7D=
;
>
>int block=5Fread(struct ures *, ...) =7B
>  // le merdier qui va bien pour lire sur un disque dur ATA par ex.
>=7D
>
>int block=5Fwrite (struct ures *, ...) =7B
>  // le merdier qui va bien pour ecrire sur un disque dur ATA par ex
>=7D
>
>int file=5Fread (struct ures *, ...) =7B
>  return libblockio=5Fread(& block=5Finterface, struct ures *, ...);
>=7D
>
>int file=5Fwrite (struct ures *, ...) =7B
>  return libblockio=5Fwrite(& block=5Finterface, struct ures*, ...);
>=7D
>
>Evidemment, on aura auparavant enregistre notre device dans la
>libblockio pour qu'elle puisse allouer un buffer permettant de
>transformer les requ=EAtes comme il faut.
>
>C'est pas optimal, parce qu'il faut recopier le code de file=5Fread,
>file=5Fwrite dans tous les drivers blocks, mais si on veut respecter notr=
e
>histoire d'interface, je vois pas trop d'autres solutions. Je vais coder
>comme =E7a. Y'aura bien entendu toujours possibilit=E9 de faire autrement=
,
>mais pour le moment, =E7a sera comme =E7a, sauf si quelqu'un trouve une i=
d=E9e
>g=E9niale aujourd'hui ;-)

Non je trouve ca normal, pour certains drivers le file=5Fread serait pluto=
t comme cela:

int file=5Fread (struct ures *, ...) =7B
 return libkio=5Frawread(& block=5Finterface, struct ures *, ...);
=7D
alors que pour d'autres
int file=5Fread (struct ures *, ...) =7B
 return libkio=5Fblockread(& block=5Finterface, struct ures *, ...);
=7D
et:
int file=5Fread (struct ures *, ...) =7B
 <begin usb file=5Frequest>
 int ret =3D libkio=5Freadfilefromuglyusb(& block=5Finterface, struct ures=
 *, ...);
 <close usb file=5Frequest>
 return ret;
=7D

C'est vrai que l'on peut en fait laisser tout a la charge du driver via le=
ur implementation de block=5Fwrite mais je pense que cela peut facilement =
devenir un peu trop le truc a tout faire.

>Ce n'est pas une d=E9cision unilat=E9rale stupide et born=E9e, c'est la
>volont=E9 d'avancer.

:)

>Bonne journ=E9e,
De meme

>Thomas

Raphael