Le 05/11/07, Yves DUF<[EMAIL PROTECTED]> a écrit :
> > Regarde la structure sysv_bb_ops dans bb_core_sysv.c pour te donner une
> > idée des fonctions à implémenter.
> > L'idée c'est donc d'ajouter un backend spécifique par l'intermédiaire
> > des bb_ops, en mettant l'implémentation du backend en question dans
> > bb_core_posix.{c,h}.
>
> Euh, j'ai un doute. Ne serait-il pas mieux d'implémenter une "couche" POSIX
> like très simplifiée, qui réponde au juste besoin TSP ?Oui pour TSP non pour le Blackboard. > La seule dépendance à l'O/S se retrouverait uniquement dans > tsp_sys_include.h > Cela laisserait le code TSP indépendant, et faciliterait l'ajout de > nouvelles fonctions. Idem. Aujourd'hui nous nous sommes attaché à ce que le code du Blackboard i.e. le contenu de src/util/libbb est TOTALEMENT indépendant du reste de l'arborescence. Il n'y a donc AUCUNE dépendances entre le code du BB et le reste du code TSP. Le "point de contact" est le bb_provider (src/provider/bb_provider) qui est lui lié aux 2 (tsp + libbb) C'est volontaire et (je pense qu') il faut conserver cette propriété car de cette façon un blackboard reste intégrable facilement à n'importe quelle application _y compris en production_ C'est en partie grace à cette NON-dépendance que ce n'était pas [trop] difficile de faire un bb kernel (enfin c'est quand Fred qui l'a fait ce qui explique que ça a été simple pour moi :=) > > Je met en fichier attaché l'implémentation de cette couche POSIX pour > vxworks (prise de l'arbo contrib de TSP) Yep dans tsp/external/VxWorks pour les curieux :=) -- Erk _______________________________________________ Tsp-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/tsp-devel
