[Kos-dev] Concernant mon travail ...

[Thomas Petazzoni]

munier@wanadoo.fr (Julien Munier) writes:

Bonsoir,

> Thomas m'a confirme ce soir qu'il continuerait sur sa lancee sans
> prendre en compte cette proposition. Et c'est bien normal! Il a besoin
> de continuer tout de suite et de voir comment ca marche, alors que
> sinon il faudrait a nouveau se poser certaines questions et ca je suis
> le premier a dire que cela a assez dure. Mais moi je n'arriverai pas a
> le convaincre du bien fonde de ma proposition, donc si quelqu'un la
> relis et la soutient, qu'il me previenne. Sinon poubelle.

Apparemment, je n'ai pas été assez clair concernant mon opinion. J'ai
pris en compte la proposition de Julien, mais je la considère comme
relativement complexe. Sa complexité est normale, car le problème à
resoudre (le chainage) et toutes les complications que cela entraine
est complexe à résoudre. Julien semble avoir réussi à pondre un modèle
qui devrait fonctionner dans ces conditions.

Mon avis n'est pas d'ignorer la proposition de Julien. Il part d'un
constat simple : on ne sait pas à l'heure actuelle, quelle est la
différence de complexité entre la solution de Julien (permettant un
empilement), et la solution que j'ai mise en oeuvre consistant à ce
qu'il n'y ai qu'un seul niveau, qui se charge d'exporter toutes les
interfaces à l'aide de librairies. C'est à partir de ceci que je pense
qu'il faut pour l'instant rester sur quelque chose de simple : le
modèle kres/ures dont j'ai brièvement parlé vendredi est extrêmement
simple (certains diront simpliste ?), mais je crois que c'est son
principal avantage.

Je ne peux pas affirmer que ce modèle sera au final plus simple que
celui proposé par Julien, car il se peut que l'utilisation des
librairies (genre libblockio) s'avère merdique, et que cela devienne
trop compliqué et trop lourd. Néanmoins, vu le temps que nous avons
passé à discuter de ceci, il me semble qu'il faudrait avancer, et pour
cela, la solution simple me semble être la meilleure.

Avancer nous permettra au choix :

 * de valider la solution simple comme étant suffisante pour ce que
   nous souhaitons faire.

 * ou bien d'invalider la solution simple, mais d'avoir pris du recul
   par rapport au problème, d'avoir pu constater les problèmes se
   posant effectivement à l'implémentation, etc.. Pour le moment on
   est le nez dans le guidon, on essaie de pondre des modèles, sans
   finalement avoir jamais codé un driver vraiment complet. Bien sûr,
   on peut faire des suppositions, mais il faut prendre du recul,
   lever le nez du guidon pour mieux comprendre ce qui nous arrive.

Et dans les deux cas, avancer nous permettra de nous lacher un peu sur
le code, de travailler sur autre chose, de reprendre plaisir à
travailler sur KOS, etc.. 

Bref, je suggère deux choses :

 * de partir sur la solution simple actuellement en
   implémentation. Cette solution a été conçue dans la majeure partie
   par Julien, et j'ai ensuite retouché le modèle en dégageant
   quelques trucs que je considérais comme inutile.

 * que Julien documente le plus possible sa proposition de modèle. Il
   serait intéressant, voire fondamental, qu'il note tous les
   problèmes auxquels il a du faire face pour trouver une solution
   permettant l'empilement. Ceci permettra, si la solution simple
   s'avère trop simpliste de réutiliser le travail déjà réalisé, et de
   ne pas remener la réfléxion menée par Julien. En combinant ces
   réfléxions, et les connaissances acquises lors de l'implémentation
   de la solution simple et de son échec, nous serons alors en mesure
   de réaliser un modèle plus complexe.

En ce qui concerne le prochain WE KOS, prévu fin mai, j'aimerai, si
vous êtes d'accord avec mes suggestions que l'on ne travaille pas à se
demander si ma suggestion est correcte, mais que l'on travaille à
l'implémenter et à coder des trucs autour de cette
solution. J'aimerais réellement qu'on avance sur d'autres parties
qu'on a laissé en repos depuis de nombreux mois (la VMM, les drivers,
la création de thread utilisateurs, les syscalls, le port d'une libc,
etc..). On a deja dit souvent qu'on allait arreter de faire et de
refaire ce modèle, mais finalement on a jamais pris de décision. 

Je ne veux pas apparaître comme le chef, qui décide de manière
autocratique de ce qu'on va faire, mais là, il faut prendre une
décision, j'émets une suggestion à laquelle j'espère que vous
adhérerez. Cette suggestion a pour but de relancer le projet.

Si vous etes d'accord, et que dans les faits, fin mai, on arrive à
travailler sur autre chose, alors je pense que le projet aura pris son
second gros virage, le premier étant celui réalisé durant l'été
2000. J'aimerai vraiment que l'on prenne ce virage, et que KOS
retrouve sa vitesse de croisière de développement : faible, mais
constante.

Mon insistance pour utiliser le modèle simple est plus liée à une
volonté d'avancer qu'à des réelles motivations techniques, j'espère
que vous le comprendrez.

En espérant ne pas avoir été trop long, et que vous adhérerez à mon
opinion, je vous souhaite une bonne nuit.

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni@enix.org - UIN : 34937744
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