Quel solution bus logiciel est il préférable d'utiliser

Bonjour,

Je suis à la recherche de solution de bus logiciels pour l'utiliser sur une plateforme embarquée ARM (noyau linux, C/C++).

J'ai bien trouvé sur google plusieurs solutions (corba, dbus, etc...) mais j'aimerai avoir plutôt un retour d'expérience sur les quelques solutions que vous avez utilisées :
- qu'est ce qui marche bien en embarqué et ce qu'il ne faut absolument pas utiliser,
- si c'est facile à utiliser où non,
- si la license est hors de prix ou libre
- si c'est performant ou pas
- si c'est consommateur de mémoire ou pas
- si vous avez utilisez votre propre solution, quel en ont été les raisons ?

Bref c'est quoi le top du top ?

Merci pour votre aide.

Cordialement

Je me suis posé pas mal de questions à ce sujet.

Je n'ai connu que des développements propriétaires dédiés...

J'ai fini par conclure qu'une architecture incluant des signaux de haut niveaux est le premier step.

Par ailleurs, on peut tester la modularité de l'architecture en supprimant des modules logiciel... et en vérifiant que le logiciel fonctionne avec les fonctionnalités restantes.

J'ai eu l'occasion de mettre en place D-Bus sur cible ARM.
Et je pense que tu te poses de très bonnes questions. Je ne m'étais pas particulièrement posé ces questions lors d'un projet embarqué sur ARM. Et je m'en suis un peu mordu les doigts après coup.

Je t'invite à lire mon retour d'expérience sur le sujet. C'est surtout la fin qui devrait t'intéresser.

Aujourd'hui si javais à recommencer, je ne prendrais pas d'IPC pour mon cas d'utilisation. Le contexte, c'était le développement de ce produit.
Tout pouvait finalement tenir dans un seul exécutable. Initialement, j'avais conçu une architecture modulaire, avec plein de daemons qui tournent en parallèle, le tout discutant sur un Bus.

Tiens, ça donnait ça.

En fait, travailler avec un bus nécessite à chaque "module" une couche de connexion, et de dialogue. Même si tu es linké par lib dynamique, tu embarques avec toi tout un bazar. Si ton vrai code (en dehors du binding) n'est pas particulièrement volumineux, j'ai réalisé qu'il était un peu "overkill" d'utiliser un IPC comme Dbus. Que cela soit pour la simplicité de développement ou pour l'utilisation de la RAM.

Bref, maintenant, je suis assez partisant du programme unique, si le projet n'est pas trop gros.

Second principal soucis avec D-Bus, c'est la licence. Tout ton code est "contaminé" en GPLV2. Tout dépend du contexte. Mais certaines sociétés verront pas d'un très bon oeil de publier tout leur code en GPLV2.

Si j'avais à réutiliser un IPC, je pense que j'utiliserais le petit bus en C que j'ai vu dans un LinuxMag il y a quelques temps. Un truc super simple, mais dont je ne retrouve plus le nom... En tout cas pour moi D-Bus (même s'il est utilisé dans Android) est pas mal overkill pour des architectures logicielles simples, et encore plus pour l'embarqué.

La question qu'il faut se poser c'est réellement : "Pourquoi ai-je besoin d'un Bus ?"

Effectivement la GPLv2 va être très problèmatique (c'est pour du propriétaire), cela plus la crainte de performances basses risque d'écarter DBUS (c'était la crainte que j'avais d'ailleurs), j'avais lu d'ailleurs ton retour d'expérience qui est très bien faite, à la question "Pourquoi ai-je besoin d'un bus ?", la réponse c'est que la plateforme va contenir un très grand nombres d'objets qui peuvent communiquer entre eux et ceux sur plusieurs plateformes qui peuvent être sur des os différents, bref c'est malheureusement pas une architecture simple. Bref j'aurais aimé ne pas être obligé de réinventer la roue (surtout avec le risque que la roue soit carré à la fin comme c'est souvent le cas). Mais bon pour l'instant il falloir que je creuse un peu plus.

Autrement c'est sympa ton lapin, il me semble l'avoir déjà vu quelque part sur le net.

Merci dans tous les cas pour vos réponses.

Sinon il y a la technique sale, de chargement de librairie dynamique à la volée, qui si je ne me trompe pas, permet de contourner le soucis de contamination de licence.