[Kos-dev] Concept de "controleur" ?

[Raphaël Junqueira]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Mardi 22 Avril 2003 11:32, Thomas Petazzoni a écrit :
> Hello,

Salut,

> [ Beaucoup de gens sur cette liste risquent de trouver ce message
> bizarre, parce qu'il parle de choses qui sont en réfléxion entre Davi=
d,
> Julien et moi-même, et nos discussions n'ont malheureusement pas eu lieu
> sur la mailing list : nous avons pris la mauvaise habitude de ne plus
> l'utiliser. ]

Si c'est pas honteux tout ca ;p

> Je vais tout de même tacher d'exposer brièvement le problème. Nous =
avons
> introduit dans KOS l'idée que l'on ouvrait une "ressource" selon une
> "interface".

allons y 

<snip>
> Malheureusement, en interne, un problème se pose en ce qui concerne
> l'implémentation des drivers et la factorisation du code.

hmmm

<snip>
> En effet,
<snip>

> Dans KOS, il faut trouver une solution différente pour factoriser ce
> code. L'idée la plus simple qu'il me vient à l'esprit est une sorte de
> "controleur" : pour chaque interface, il y a un controleur a qui on
> passe un identifiant de driver et qui propose toutes les méthodes de
> l'interface. Dans le cas de block, la fonction read() du controleur
> gérerait le cache, les problèmes de fragmentation/défragmentation, =
etc..
>  en s'appuyant sur la méthode read() du driver passé en paramètre.

Logique, et je ne voit tjs pas l'interet du mapping direct 
INTERFACE->IMPLEMENTATION.

	En clair, moi je le voyait plutot un "controleur" qui fournirait "une 
implementation par defaut/generique" et dechargerait les parties speciques a 
des modules dedies (drivers)
	Pour quoi donc, me dirait tu ? Ben prenons l'exemple d'une gestion de bus (ce 
en quoi hurd est une calamite) une grosse partie du code de gestion est et 
doit etre partagee car:
 -  les infos sur les IOs doivent etre regroupees afin d'avoir un scheduleur 
d'IO digne de ce nom
 - tous les bus sont interdependants dans leurs acces (vive la joie des acces)
- - ...

> De toute façon c'est une idée un peu comme celle-ci qu'il faut (je
> pense) utiliser. La question maintenant est : est-ce que ce problème de
> factorisation de code est inhérent à block et à ce moment là il f=
aut
> trouver une solution spécifique à block, ou alors est-ce que ce probl=
ème
> risque de revenir avec de nombreuses interfaces, auquel cas il faut
> trouver une solution globale pour le système.

	Non elle n'est pas inherente au bloc, mais aussi a la gestion des bus, et de 
pleins d'autres styles de peripheriques. De plus on peut "piper" :) par 
exemple avec la gestion de bloc qui passe qquesoit le bus (exemple tordu via 
le bus USB: c tres bo ca aussi)
	Dans la liste a fort dose de factorisation, on trouvera aussi surement les 
cartes sons et cartes graphiques.

> Voilà le fruit de mes réflexions. J'espère réellement qu'on trouv=
era une
> issue à ce problème, car j'attends les solutions pour pouvoir me lâ=
cher
> sur le codage ;-)

  J'espere que ca t'aidera a te lacher ;)

> Bonne journée,

a toi aussi,

> Thomas

Amicalement,
Raphael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+pwRJp7NA3AmQTU4RAgykAKCFhbLxAW+kxrEXKxLosRs6kizQNgCeM4OH
8r4LER5O5qtpV5jTUALHiq0=
=7Crh
-----END PGP SIGNATURE-----