[Kos-dev] Utilisation du C++

[Anthony Jaguenaud]

Thomas Petazzoni wrote:
> Hello,
> 
> Un long moment d'inactivite, mais KOS reste toujours dans mon
> esprit. Le developpement est actuellement "bloque" par Babel, qu'on
> essaie de mettre en place. J'en ai marre d'etre "bloque" par ce truc
> la, j'ai envie d'aller de l'avant.
C'est normal de bloquer en informatique, si tu bloques pas, c'est que tu 
ne realises rien de complique.


> Voila ce que je pense :
>  * l'utilisation du C++ nous embarque trop loin. ce langage est
>  complexe a utiliser techniquement (cf libcxxrt), il s'interface tres
>  mal avec le code C existant, et on risque d'utiliser des choses
>  douteuses. A mon avis, si l'OS n'est pas structure des le depart avec
>  un langage objet, on va droit dans le panneau. Et personnellement, je
>  ne me sens pas de refaire tout KOS en C++ (ou alors si, mais dans 20
>  ans). 
Je suis d'accord, il faut penser un projet des le debut en objet. Dans 
le cas qui t'occuppe, je ne sais pas. Mais transforme du C en C++, c'est 
jouable a condition de pas modifier les interfaces. Sinon, il faut 
refaire les interfaces, mais comme des wrappers des fonctions C. Le 
faire progressivement.
Reprendre KoS en C++ depuis 0 ?
Attention quand meme, une fois l'analyse terminee, il sera plus 
difficile de rajouter des verues au projets s'il est en langages objets. 
Enfin, a condition de vouloir garder la coerance.

>  * nous n'avons pas vraiment besoin de l'heritage au niveau de
>  l'interface. Un meme "driver"/"module" peut exporter plusieurs
>  interfaces. Je pense au contraire que l'heritage au niveau de
>  l'interface permet trop de souplesse et ne nous force pas a
>  concevoir correctement les interfaces. 
Heu, je pense que c'est au contraire tres bien de definir une interface 
*fixe* sur un objet virtuel, et implementer uniquement des fils.
Comme pour un disque.
class Disque ; puis :
class DisqueIDE:public Disque ;
class DisqueSCSI:public Disque, public PeripheriqueSCSI ;

Sur un objet Disque SCSI, tu peux recuperer  une interface Disque, ou 
une interface PerepheriqueSCSI avec un dynamic_cast ( de memoire ).

>  * il faut decider une chose tres importante : est-ce que l'on doit
>  centraliser la gestion des instances, ou est-ce que ce sont les
>  modules eux memes qui doivent se charger de la gestion de leurs
>  instances. 
Moi, je vois tres bien un objet instancie par le systeme :
class Ordi {
	list<Disque &>
	list<CarteGraphique &>
	list<InputDevice &>
};
Chaque module essaye de se loader.
Ex: Le module DisqueIDE demarre, detecte 2 disques, qu'il ajoute a la 
liste de Ordi.
Le module DisqueSCSI demarre, mais ne detecte pas de disque. Il 
n'instancira rien.


> Le dernier point est particulierement important. Dans le cadre d'un
> langage orienté objet, la gestion des instances est réalisée
> automatiquement. Dans KOS, il convient de decider si l'on souhaite
> centraliser cette gestion, ou si l'on prefere que chaque module
> s'occupe de maniere independante de ses données.
Bien, je pense qu'il faut que chaque module gere ses donnees, qu'il 
puisse acceder au donnee d'autre module qui peuvent lui etre utile, ... 
C'est la la difficulte, creer quelque chose de fiable, facilement 
updatable, tout en ne nuisant pas trop aux perfs...


> Je n'ai pas de reponse tout faite a fournir, juste une envie de lancer
> la reflexion sur ce sujet.
Moi non plus, en plus je sais pas trop comment marche votre system en 
interne. Mais bon, se sont juste des idees, utiles ou pas, a vous de me 
le dire.


> Bonne soirée,
Bon week end

Anthony

-- 
------------------------------------
Anthony JAGUENAUD
NORTEL NETWORKS
R&D PCU Developpement
e-mail : jaguenau@nortelnetworks.com
tel    : 01.69.55.55.09 ( ESN 574 )
------------------------------------