[Kos-dev] Deux questions sans reponses

[Fabrice Gautier]

On Sat, 14 Jul 2001 15:33:23 +0200
Thomas Petazzoni <thomas.petazzoni@ifrance.com> wrote:

> ouais mais bon y'a besoin de recompiler quand meme. arf, c'est
> desesperant cette informatique, on peut pas tout faire comme on aimerait
> le faire :)

Ben oui faut au moins compiler une fois tous les codes sources que tu
modifie. Mais tu ne dois pas être obliger de recompiler le code que tu
n'as pas modifié

Si l'interface change complétement, il te faut changer le code du driver
qui implémente cette interface et le code qui l'utilise (le client).
Donc tu les recompiles et c'est normal.

Si l'implémentation change, et que l'interface ne bouge pas, tu modifie
(et donc recompiles) seulement le driver, les clients ne doivent pas
avoir besoin d'etre recompiler.

Maintenant je pense que la VRAI question que tu soulèves c'est si je
rajoute une fonction dans l'interface, que j'ai un client qui n'utilise
que l'ancienne interface, je n'ai pas besoin de modifer le code de ce
client mais est-ce que j'ai besoin de le recompiler? l'idéal serait non
mais la ca devient plus délicat. 

En fait quand tu recompiles ton interface tu regénère un nouveau stub.
Ce stub c'est quoi finalement, c'est le .so dont on parle.

Bon et bien un .so si tu le recompiles tu n'as pas besoin de recompiler
tes applis. Evidemment si tu veut linker en statique ca devient embetant.
En effet ton stub serait linker statiquement avec ton client et du coup
si l'ancien stub ne convient plus à la nouvelle interface ca va merder.

En CORBA je recompilaistout toutle temps parce que en fait je sais pas
comment sont liées les choses, surtout en java... 

Par contre une solution en CORBA, et si on veut garder la compatibilité
avec des client liés statiquement, c'est de ne pas toucher à l'interface
et de créer une nouvelle interface qui hérite de l'ancienne. Ainsi on ne
recompile que la nouvelle interface et on génère un nouveau stub. C'est
une façon de faire des version pour une interface.
(En fait j'ai pas vraiment testé ça, mais ça me parait correct)



> > babel.kpkg
> >  (
> >    - babel.ro
> >    - include/babel.h
> >    - babel.so
> >  )
> 
> On peut imaginer ca, mais ca va etre assez complexe : pour charger des
> modules, t'as besoin d'un FS, donc il peut pas etre en module. Ensuite
> il faut que ton module soit charge avant meme que tu n'accedes a une
> ressource utilisant ce module.

Voir initrd? 
(ou le nouveau truc prévu linux 2.5: le kernel filesystem - si ca
s'appele comme ca)

> C'est faisable, mais ca marchera pas pour tout. Il y aura des modules du
> noyau exportant des methodes vers le CPL3 qui pourront pas vraiment etre
> implementes en module chargeable dynamiquement.

Forcément, mais je crois pas que ce soit son système de package qui
impose ca. Ca à toujours été vrai.


-- 
Fabrice Gautier <gautier@email.enstfr>