Re: [Tsp-devel] [RFC] Modificat ions à venir sur le black board

[Eric Noulard]

2006/7/17, Frederik Deweerdt <address@hidden>:
> Salut liste,
>
> J'ai un prototype de black board dans le kernel qui "marche" (c'est à
> dire que les appels bb_tools fonctionnent et qu'on peut y mettre un
> tsp_bb_provider dessus).
> Côté kernel, l'API est la même que côté user: bb_create,
> bb_simple_publish, du côté des outils bb, il suffit de donner le
> device bb associé: bb_tools bb_dump /dev/bb0.
> C'était pour la bonne nouvelle :).

Je savais que l'été serait chaud mais là...
C'est brulant :))

> La mauvaise c'est que les changements sont assez intrusifs : le diff
> fait près de 60Ko. Voici un petit résumé des impacts:
> 1) des #ifdef __KERNEL__ autour des include espace utilisateur
> 2) des #ifdef __KERNEL__ autour des doubles et float
> 3) déplacement de la partie SysV de bb_core dans bb_core_sysv.c
> 4) ajout du code kernel proprement dit dans bb_module.c et bb_core_k.c
> 5) ajout dans bb_core une couche d'abstraction entre l'API bb_* et
> l'implémentation propremment dite par l'intermédiaire des struct
> bb_operations.
> 6) modifs nécessaires dans les CMakeLists.txt pour compiler le module
> à la demande

3 et 5 sont très utiles pour des éventuels portages BB vers d'autres
environnements
qui n'auraient pas d'API SysV.

> Avez vous une préférence pour le timing ou la façon d'intégrer les
> modifs. Je voyais les trois possibilités suivantes:
> - je commite uniquement  3 et 5, pas de code kernel, on laisse passer
> une version de TSP, puis on voit pour la suite
> - je poste les patches sur la liste, scindés en entités logiques
> (grosso modo le découpage ci-dessous), et on commite une fois que tout
> le monde à relu et approuvé.
> - je commite tout et chacun pourra essayer à partir de l'arbo, tout ça.

Personnellement j'imagine une quatrième possibilité.
Tu crées dès maintenant une branche de DEV à partir de l'arbo
BB up to date (idéalement la version dont tu es parti à toi de vérifier
si il y a eu des changements depuis)

Creation de la branche CVS:

cd tsp/src/util/libbb
cvs update -A -d .
cvs tag -b br_BB_KERNEL_DEVEL

Tu te positionnes dans la branche:

cvs update br_BB_KERNEL_DEVEL

Tu y copie/merge tes modifs puis tu commites TOUT
DANS LA BRANCHE.

De cette façon:
  1)  tu peux gérer en conf tes modifs à venir
  2) n'importe qui peut tester en se mettant dans la branche pour le BB

Ensuite je pense que tu peux d'ores et déjà merger sur le trunk
les modifs 3 et 5.

On passe une petite (i.e. courte) période de test
(et relecture de code) avant de ramener
le tout sur le trunk et de couper la branche...

En gros c'est comme ta solution 1) sauf qu'on créer une branche
CVS ce qui nous permettra de faire quelques commit/diff collaboratif
(probablement) plus efficacement que par mail.
Celà te permettra à toi également de continuer un peu de DEV
éventuel avant le merge.

Voilà mon avis.

> $ bb_tools bb_dump /dev/bb1
> ============= <[begin] BlackBoard [bb_test2] [begin] > ===============
[...]

Que du bonheur :)))

Une question subsidiaire, tes modifs ont-elles eu des impacts sur
le (code du) bb_provider ?
Si oui n'oublies pas de les commiter avec 3 et 5.
Quitte a créer également une branche
br_BB_KERNEL_DEVEL pour src/provider/bb_provider


--
Erk