[Kos-dev] Libblockio

[kos-dev@enix.org]

>De: Thomas Petazzoni <thomas.petazzoni=40enix.org>
>
>Hello,
>
>> Je verait plutot une libkio plus generique qui gererait tous sorte d'ac=
ces par io (et ne pas se limiter au acces par blocks, certains periphs con=
sideres par blocs ne fonctionnent qu'en raw commes d'autres que par requet=
es a la granularite fichiers).
>
>Non, justement le but c'est d'avoir un truc qui fait juste =E7a : il ne
>faut pas tout m=E9langer AMHA.

Vi j'avait compris, mais je trouve ca une peu limite d'une lib juste pour =
les acces par blocks mais pkoi pas.

>> 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
>
>Tu peux expliquer la diff=E9rence entre =22raw=22 et =22block=22 ?

=22raw=22 pour moi signifie acces direct donc non bufferise.
les acces par =22block=22 supposent une granularite pas block (soit de fs,=
 soit de reseau, ...) donc d'une semantique bien plus grande que les acces=
 =22raw=22 souvent par blocks materiels.

>
>> int file=5Fread (struct ures *, ...) =7B
>>  <begin usb file=5Frequest>
>>  int ret =3D libkio=5Freadfilefromuglyusb(& block=5Finterface, struct u=
res *, ...);
>>  <close usb file=5Frequest>
>>  return ret;
>> =7D
>
>Oula, non, non, non l'ami : la libkio n'a aucune connaissance de
>readfilefromuglyusb : c'est les fonctions de block=5Finterface qui savent
>faire =E7a. La libkio n'a *RIEN* de sp=E9cifique au mat=E9riel, elle est =
juste
>l=E0 pour convertir du byte-grained en block-grained et =E9ventuellement
>faire du cache. C'est tout =21

ok donc en clair elle permet le =22raw=22 -> =22block=22 et facilite la ge=
stion des =22blocks=22 ?
Donc libkio n'est clairement pas parlant plus adapte serait qquechose du g=
enre libkutil=5Fblockio.
Moi je me basait plutot comme centralisateur des differents drivers d'io (=
d'ou le nom libkio) et permettait le =22pipe=22 de drivers (cf mon libkio=5F=
readfilefromuglyusb qui serait implementer par le driver usb). =


>> C'est vrai que l'on peut en fait laisser tout a la charge du driver via=
 leur implementation de block=5Fwrite mais je pense que cela peut facileme=
nt devenir un peu trop le truc a tout faire.
>
>Euh, pourquoi ?

cf mon commentaire ci-dessus.
Je partait d'un niveau d'abstraction plus eleve. Si tu te limite aux block=
s le probleme ne se posera pas mais les differentes implementations d'acce=
s par blocks auront comme dependance d'avoir acces a l'ensemble des interf=
aces d'io. Donc de nombreuses autres libs de plus haut nivo que blockio

>Le but d'un driver, c'est bien de =22driver=22 non ? (Prononcez =22driver=
=22
>comme =22driv=E9=22 sinon ca le fait pas). Donc le driver se charge de fa=
ire
>ce qu'il faut pour aller triturer le ATA ou l'USB pour aller lire block
>par block (dans le cas des p=E9riph=E9riques blocs), et la librairie perm=
et
>=E0 partir de l=E0 d'exporter une interface de type =22fichier=22.

Ce n'est pas a un driver de disque dur USB de gerer le protocole USB. Il d=
oit avoir acces aux APIs du driver USB et lui ne fait que de l'utiliser po=
ur implementer les acces par blocks du disque dur USB non ?

>Thomas
Raphael