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

[Thomas Petazzoni]

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

Hello,

> ok alors disons chainage ?

Oui, si tu veux.

> je reviens juste sur les conneries que j'ai dit pour montrer que dans ma
> betise se cachait surtout de la naivete ;-)

Mais non ;) Cf mon autre mail qui vient juste d'être envoyé.

> mouais, sauf que je me souviens que tu m'avais dit que le code de part
> pouvait etre generique non ? donc on peut imaginer une libraire au meme
> sens que la lib de cache. bon, disons que comme souvent mon exemple est
> mauvais.

Non ce n'est pas une librairie, parce que "part" exporte lui aussi
l'interface block, et tu dois remettre au dessus un libblockio. Les
/dev/hdaxx sont des blocks devices, comme /dev/hda, et on doit donc
mettre libblockio dessus pour que ce puisse être considéré comme un fichier.

--------------                --------------
| libblockio |                | libblockio |
--------------                --------------
      ||                            ||
      \/                            \/
--------------                 -------------
|    part    | ------------->  |    ata    |
--------------                 -------------

-> Part n'est pas une librairie, c'est un driver. Bizarrement, il repose
sur ata pour lire des blocks, mais c'est un pur hasard ;)

> disons que c'est implicite, tu appliques d'abord un driver et par dessus
> tu chaines avec des librairies ... (dans mon idee part etait une
> librairie et par ailleurs dans mon idee il n'y a pas de distinction
> entre l'interface implemente par un driver et les interfaces implementee
> par des translators)

J'ai pas trop compris ce qu'il y avait dans la parenthese, parce que ca
parle de translator, et je sais pas ce que c'est dans la terminologie KOS.

J'ai juste compris que tu mets un driver, et dessus tu mets des trucs
qui traduisent les interfaces. Mais si tu regardes le mail que je viens
tout juste d'envoyer, tu verras apparaitre quelques soucis, que tu ne
vois pas quand tu envisages seulement un driver avec *une* interface.

> passons sur cet exemple maladroit j'avais besoin d'un truc a ecrire.

Il n'était pas maladroit, parce que le problème de part -> disk driver
doit etre résolu.

> au niveau du driver il choisit l'interface implemente par le driver, au
> niveau des librairies (translator) il se comporte differemment, il
> utilise LA librairie.

"il choisit l'interface implemente par le driver" ?

"LA" librairie ?

> c'etait juste par rapport a l'idee que le noyau ne manipule par de ures.

Bon alors c'est des kres tuning ;)

> autant que moi ? :-)

Peut être ;)

> Les notions de drivers qui implementent une interface et de translators
> qui fournissent un truc qui s'assimilent (par le plus grand des hasards
> comme tu l'as dit) a une interface implementee doivent etre les deux
> objets qui permettent de construire le chainage (ou le modele en couche)
> selon la terminologie de ce mail, non ?

Oui, si on veut, mais ca ne colle pas avec notre modèle. Je vais essayer
de rédiger un mail plus long à ce sujet. Je suis au boulot, alors c'est
vrai que je prends pas trop le temps d'écrire des choses de trois
kilomètres. Ton idée est excellente, mais regarde ce qu'il y a dans mon
autre mail, où je réagis à mes propres réactions.

Sachant que *UNE* kres peut être vue selon *plusieurs* interfaces,
comment tu fais si "ata" exporte 3 interfaces, dont block ? Je veux
dire, comment elles sont encore accessibles à l'utilisateur si tu mets
un bordel (libblockio) dessus qui sait juste faire du "file" a partir de
"block" ?

> n'y a t'il pas une possibilite de dire que ces translators implementent
> des interfaces ? de faire converger les deux trucs ?

Si tu veux faire un modèle en couche, clairement, il faut que libblockio
exporte (et donc implémente) l'interface "file", ca c'est clair. Mais il
faudrait quand même qu'on puisse accéder à block et autres interfaces,
cf schéma :

  BLOCK      FILE        DISK_PERF_TUNING
    ||         ||          ||
    ||         \/          ||
    ||     libblockio      ||
    ||<--------|           ||
    \/                     \/
 ------------------------------
 |        ATA                 |
 ------------------------------

Tu vois le problème ? Il faudrait que la traduction permette simplement
d'ajouter une interface (en se basant sur des interfaces sur driver sous
jacent) ou de transformer une interface (faire une interface block
bufferisée à partir d'une interface block non bufferisée par ex).

Je crois que ce dernier schéma explique bien le problème que je vois. Je
pense qu'il est *surmontable* mais il faut réfléchir à son implémentation.

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

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

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

iD8DBQE+qTk99lPLMJjT96cRAsCtAJ0RNLWr8o5GjFWd4n7odaQQ25fY1ACghUKj
0P5QAAcaAOlLvkiz9EKzts4=
=Duw4
-----END PGP SIGNATURE-----

--------------enig7613A522C1914B0EA14188AE--