[Kos-dev] Travail de la semaine derniere, aspect methode

[d2]

Bonjour,

La semaine qui vient de s'ecouler, Thomas et moi avons travaille
quelque peu sur Kos, et la semaine d'avant a ete consacree a 2 articles
a paraitre. Point principal au niveau Kos : changement d'approche dans
le developpement. Le reste, c'est que du "technique", mais c'est
interessant quand meme (mail a venir).

Jusqu'a present, quand on partait a developper quelque-chose, avant ca
on commencait par "prevoir", on "anticiper", bref on triturait nos
neurones pour trouver un "modele" complet cense couvrir tous les
cas... envisages. Seulement apres on se mettait a coder, le plus
souvent pendant une des reunions Thomas/Julien/moi. Et comme,
forcement, le temps manquait pour coder la chose completement, on
avait des bouts de fonctions inacheves, des champs obscurs dans des
structures, etc... qui se revelaient inutilisables quand on y revenait
3 mois plus tard. Et puis en y revenant 3 mois plus tard, apres avoir
creuse un peu la litterature sur le sujet de nos delires, on se rendait
compte que finalement notre usine a gaz etait 1/ bien complexe, 2/ pas
si complete car elle avait traite plein de cas envisages, mais pas les
points les plus iportants et fondamentaux, non envisages...

Maintenant qu'on commence a avoir assez de recul, je pense que ce
comportement est simplement le reflet du fait qu'on manquait justement
d'une vision globale de ce qu'est un OS. Comme on travaillait aspect
par aspect (loader, puis vmm, puis babel, puis...), on avait une
succession de visions locales de chaque probleme, et nos delires
d'anticipation venaient surement du fait qu'on n'arrivait pas a
articuler ces points ensemble : on etait obliges de prevoir des cas
bizarres, des modeles usines a gaz parce qu'on ne cernait pas de facon
suffisamment synthetique comment ca allait s'organiser avec le reste.

Bref, maintenant je ne dis pas qu'on a tout compris de comment on fait
un OS, mais en tous cas, je pense qu'on a compris un de nos travers
principaux. Donc l'approche de la semaine passee ca a ete : "slim fast
tendance simple is beautiful" ) On a essaye d'avancer cote babel en
virant, lors des survols du code existant, le code superflu qui
correspondait a nos delires d'anticipation (genre le champ
"alone_on_pt" dans les virtual regions). L'idee, c'est de faire un
truc operationnel, pour lequel on peut avoir une vision de bout en
bout : du noyau jusqu'au cpl3, en passant par la VMM et le VFS, avec
mapping, lecture de fichiers et drivers. Quitte a reprendre le code,
revoir des details plus tard quand des trucs ne conviendront plus
(genre la synchro, tout simplement mise de cote pour le moment). Le
fait d'avoir une vision globale nous permettra (on l'espere) de savoir
ce qui ne va pas, ce qu'il aurait fallu faire, etc... A posteriori,
certes, mais ca evite les delires voie-de-garage de nos
anticipations. C'est un peu l'anti-methode recommandee pour faire un
bon logiciel, mais une chose est sure : comme on n'arrive pas a faire
des specs correctes sans avoir deja vu les problemes "concretement",
commencons par essayer un truc, et poussons le au bout. Apres, on
regarde comment ca marche pas, et on revoit la chose, ou peut-etre
autre chose dans le systeme qui ne convient plus.

Voila pour un retour d'experience. Pour les avancees techniques,
attendez quelques heures ou quelques jours (un peu charge), ou lisez
le ChangeLog sur les sources
(http://kos.enix.org/cgi/cvsweb/~checkout~/kos/ChangeLog).

Bonne journee,

-- 
d2