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

[Thomas Petazzoni]

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

Hello,

[ Réactions à chaud ]

> : j'appelle ca la serialisation, je me trompe de terme vous me
> corrigerez.

Je n'appelerai pas ça la sérialisation, parce que je crois que le terme
"sérialisation" a une sémantique bien spécifique en informatique, et qui
n'est pas celle-ci. Mais peu importe, je crois avoir compris le
principe, qui est, en gros, celui que je t'avais exposé lors de notre
dernière rencontre sur Montpellier.

> en fait il faut qu'on puisse ouvrir une resource d'apres une liste
> d'interface a appliquer.

Je ne suis pas sur que ce soit une "liste d'interfaces a appliquer",
parce que tu ne peux pas appliquer une interface : tu ne peux que
utiliser des implémentations.

>. elles se rapprochent plus de librairies dans le
> noyau par exemple la gestion des partitions ou des caches blocks, ou
> de la crypto ou des pseudo-tty par exemple.

Il est clair qu'il y a beaucoup de cas ou le code est factorisable, et
ou on aurait interet a avoir un fonctionnement par couches (ce que tu
appelles sérialisation).

> donc il faut modifier tout ca. en particulier parce que le
> comportements des drivers qui implementent les interfaces et les
> librairies qui implementent des interfaces ne fonctionnent pas de la
> meme maniere.

Les librairies (genre libblockio) n'implémentent pas d'interfaces. Elles
permettent juste (et c'est un *PUR* hasard) de créer de manière très
simple une interface "file" à partir d'une interface "block". Un
traducteur en quelque sorte. Un translator ;-)

> on a donc une libraires part mais aussi on admet que /dev/hda
> implemente l'interface block et qu'on a aussi une libraire
> libblockcache.

Une librarie "part" ? Un driver "part" je dirais plutôt : rien ne
différencie une partition d'un disque dur, ce sont tous les deux des
blocks devices, gérés par leurs drivers respectifs, et auxquels on peut
accéder via l'interface block.

>       rd = open("/dev/hda","block|libblockcache:bs=512|part");

Pop pop. Incohérence dans ta description de chaine :
 * block est une interface
 * libblobkcache est une librairie
 * part est un driver

Je vois pas comment le système peut deviner tout ça. Et ton appel il
fait quoi exactement ? Il génère les partitions qui se trouvent sur le
disque /dev/hda ? Pourquoi "part" aurait-il besoin d'un libblockcache
sous jacent (sachant que pour lire la table des partitions, on fait des
lectures bloc par bloc) ?

> donc il faut transmettre une structure de donnees qui decrive les
> differentes interfaces et leur parametres de configuration lors de
> l'appel open.

Mouais.

[ Structure de données ]

Si tu donnes une interface pour chaque "level", le système il choisit
quelle implémentation ? Au hasard ?

> a ce moment la dans le code du open il faudra changer des trucs : en
> effet la serialisation implique que le noyau manipuler des ures or on
> veut que les ures soient juste pour le nivau utilisateur donc il peut
> etre utile d'utiliser une autre structure : sres pour serialized
> resource en somme.

J'ai pas beaucoup réfléchi, mais à mon avis, une ures reste une ures :
un objet sur lequel on peut appliquer des méthodes. Après si y'a tout un
bazar derrière pour faire fonctionner l'ures, c'est un autre problème, à
gérer avec des structures de données internes.

Je me trompe peut être, mais je vois pas pourquoi remettre en cause le
modèle des kres/ures à cause de cette sérialisation.

> la structure de sres est une forme canonique de la structure de ures
> en fait. mais c'est une question de principe en fait.

Euh ?

> ainsi une fois qu'on a implementer la serialisation, tous les
> problemes de factorisations de code seront gere de facto.

Moi j'appelle sérialisation le modèle en couche, mais peu importe. Et
effectivement, c'est un problème majeur pour la factorisation de code.
Je pense que tu as bien identifié le problème, que la solution de monter
des choses en série les unes sur les autres est la bonne. En revanche,
en ce qui concerne l'implémentation que tu proposes, je suis beaucoup
plus septique.

Ca ressemble *très* *très* fort à ce que je fais en ce moment tout ça.

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

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

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

iD8DBQE+qS2y9lPLMJjT96cRAoCUAJ9Q38VU1ANdWI7vm3HYkqNM+2v4fwCdHOS6
hmSZsOwvdAGGzNzZ5+eXiRE=
=bnQj
-----END PGP SIGNATURE-----

--------------enig3B32ADC8C0314872947F3D31--