Alors que Linux embarqué monte en puissance, il est souvent nécessaire de disposer d'un bus logiciel permettant de faire communiquer les différentes briques du middleware entre elle. Le monde des bus étant déjà bien rempli, la question voudrait de se poser la question sur la pertinence sur un nouveau ? En effet, il en existe un certain nombre mais pour la plupart ce sont des bus issus du monde des desktops ayant été portés pour l'embarqué, sans aucune adaptation.
Un exemple est Dbus qui est fréquemment utilisé. Il s'avère qu'il est consommateur en ressources et notamment en changements de contextes vu que toutes les communications se font en sockets BSD en AF_UNIX ou AF_INET autour d'un daemon central.
Le lancement d'A-Bus a été lancé autour de l'idée de n'avoir aucun daemon, d'avoir une faible empreinte mémoire et processeur, et avec une utilisation assez triviale. Le développement a été réalisé en langage C mais un binding C++ est disponible. D'autres pourront être apportés plus tard pour python ou ruby entre autre.
À l'instar de Dbus qui s'articule autour de messages XML via la librairie Expat (ou autre), A-Bus a fait le choix de JSON. En effet, via un plugins fcgi pour lighttpd, une extension est possible pour des applications web permettant ainsi d'offrir une IHM web 2.0 à des appareils embarqués et ce très facilement.
Il est fourni avec un série d'exemples et une chaîne de tests unitaires basé sur le framework google/test. J'espère que ce bus vous aidera pour alléger vos développement en GNU/Linux embarqués.
Enjoy !
Aller plus loin
- Site officiel du projet (1078 clics)
- Documention au format doxygen de l'API (136 clics)
- Exemple illustrant l'utilisant du bus (457 clics)
- Licence GPL (38 clics)
- Websvn du projet (38 clics)
- Wiki (98 clics)
- Remontée de bug (18 clics)
- Téléchargement (46 clics)
- Liste de diffusion (53 clics)
- Roadmap (102 clics)
# C'est bien.
Posté par magnetik (site web personnel) . Évalué à 5.
Les transports en commun c'est bon pour la planète.
[^] # Re: C'est bien.
Posté par Elfir3 . Évalué à 10.
<humour noir>
En suisse, ça va même jusqu'à apporter une solution à la surpopulation planétaire.
</humour noir>
[^] # Re: C'est bien.
Posté par zebra3 . Évalué à 0.
En plus, ça règle le problème de la pédophilie : plus d'enfants, plus de pédophiles.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: C'est bien.
Posté par ナイコ (site web personnel) . Évalué à 10.
Ça suffit, les jeux de mots, je trouve qu'il y a de l'A-Bus, là…
[^] # Re: C'est bien.
Posté par Antoine J. . Évalué à 10.
Au contraire je trouve que c'est un bon Dbus.
[^] # Re: C'est bien.
Posté par totof2000 . Évalué à 3.
Faut faire attention, s'il a trop Bus, il pourra pas conduire.
# Comment ça marche ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Et ça marche comment au juste, sans démon, ni socket réseau ou Unix ? Des tubes nommés, des fichiers temporaires (beurk !) ?
[^] # Re: Comment ça marche ?
Posté par Gui13 (site web personnel) . Évalué à 4.
Probablement qu'ils utilisent les sockets UNIX (la dépêche ne dit nulle part qu'ils n'utilisent pas ça), mais après tout, dans l'embarqué t'es bien content d'avoir un processus "broker" en moins à gérer…
Confirmation ici: http://code.google.com/p/abus/source/browse/trunk/abus/sock_un.c
Par contre j'ai l'impression qu'ils ferment la porte aux sockets INET, ce qui est très dommageable si tu veux que ton embarqué puisse exporter une API sur le réseau local…
[^] # Re: Comment ça marche ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Ça donne quand même vachement l'impression qu'ils reprochent à D-Bus d'utiliser des sockets…
[^] # Re: Comment ça marche ?
Posté par Gui13 (site web personnel) . Évalué à 9.
Je pense surtout qu'ils reprochent à DBUS d'utiliser 2 sockets UNIX pour communiquer d'un client à un serveur.
Typiquement, D-BUS c'est ça:
Pour chaque requête D-BUS, tu vas écrire dans la socket 2, puis le broker va copier le contenu de ta requête et l'écrire dans le socket 1, et pareil au retour pour la réponse.
Tu multiplie les
read()/write()/select()dans tous les sens, et donc les appels système. C'est ça qui est chiant.Avec un système où le serveur fait office de broker (usage typique d'un middleware), tu as ça:
Une seule paire de
read()/write()et c'est parti. Tu divises les appels système par 2.En terme de coût d'IPC, sur de l'embarqué, je pense que D-BUS est vraiment pas avantageux.
Certes, la notion de broker permet de faire plein de trucs délirants (pub/sub machin truc), mais ça n'a de sens que sur de Desktop où tu as pidgin, thunderbird, firefox, mpd et 150 autres processus utilisateur qui tournent.
[^] # Re: Comment ça marche ?
Posté par chicco . Évalué à 10.
Il est possible de n'utiliser qu'un socket avec D-BUS: il y a une fonctionnalité pair-à-pair.
En gros quand 2 processus savent qu'ils vont échanger beaucoup de données, ils peuvent choisir de négocier une connexion directe. C'est ce que fait GIO je crois.
Sinon D-BUS ne communique pas avec des messages XML. XML est juste utilisé pour décrire les interfaces des services.
[^] # Re: Comment ça marche ?
Posté par Larry Cow . Évalué à 1.
Oui, mais cette connexion directe il faut la négocier avec l'accord du broker, non?
[^] # Re: Comment ça marche ?
Posté par liberforce (site web personnel) . Évalué à 6.
Pour ce qui est de DBus: on sait depuis longtemps qu'il a un soucis de performance. Il y a un travail de fond qui est à l'œuvre actuellement, mais la solution technique fait débat. La création d'une nouvelle famille de socket a été refusée dans le kernel, et depuis on s'oriente vers l'utilisation de Netlink.
Voir cette série d'articles tout frais de Rodrigo Moya, qui travaille pour Collabora à l'intégration de ces modifications pour GENIVI (consortium autour d'une plate-forme Linux multimédia dans l'automobile):
http://blogs.gnome.org/rodrigo/2012/02/27/d-bus-optimizations/
http://blogs.gnome.org/rodrigo/2012/03/07/d-bus-optimizations-ii/
http://blogs.gnome.org/rodrigo/2012/03/20/netlink-based-d-bus
LWN avait aussi couvert ce sujet:
http://lwn.net/Articles/466304/
[^] # Re: Comment ça marche ?
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
Ce qui m'étonne, c'est que DBUS devait être un truc léger pour virer cette couche Bonobo/CORBA qui était bien trop lourde… Ou a été l'erreur si erreur il y a eu ?
[^] # Re: Comment ça marche ?
Posté par liberforce (site web personnel) . Évalué à 6.
C'était peut être encore pire avant ;-). Ou peut être qu'on en fait une utilisation plus massive et que cela ne tient pas la charge… Mais il est vrai que la question est intéressante.
[^] # Re: Comment ça marche ?
Posté par totof2000 . Évalué à 7.
Ben là on fait comme beaucoup de soit-disantes "améliorations", libres ou pas, mais que jhe trouve plus flagrantes dans le libre.
"
- J'ai besoin d'un bus logiciel
- Ah bien utilise Corba
- Ah oui mais c'est lourd
- Oui mais tu peux faire plein de choses avec
- Oui mais c'est trop lourd, je vais inventer un bus plus léger => DBUS "
Le temps passe, puis on découvre que le bus léger, il pourrait faire aussi des trucs plus louurds, et on redéveloppe le truc d'origine en moins bien et en moins efficace.
Pour ma part c'est pour ça que je ne suis pas chaud lorsque j'entends qu'il existe des initiatives pour virer X11 et développer autre chose à la place : on va réécrire un truc qui marche pas trop mal en repartant de zéro, sans se poser de questions, et au final obtenir un truc plus louurd, moins portable et complètement pourri.
[^] # Re: Comment ça marche ?
Posté par reno . Évalué à 2.
Surtout que comme X11 a l'extension DRI2 (écrite en grande partie par le développeur principal de Wayland d'ailleurs), il n'y aura (à priori) pas vraiment de gain de performance..
[^] # Re: Comment ça marche ?
Posté par claudex . Évalué à 3.
C'est une simplification de l'architecture qui est visée pas une augmentation des performances.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Comment ça marche ?
Posté par ymorin . Évalué à 3.
Alors, dans ce cas, je préfère la vieille architecture performante, plutôt que la nouvelle simplifiée.
Bon, sûr, à terme, la simplification vas potentiellement amener une amélioration des performances, vu qu'il y aura moins de couches à traverser…
Seconde loi de Jim READY:
Hop,
Moi.
[^] # Re: Comment ça marche ?
Posté par reno . Évalué à 2.
La nouvelle simplifiée n’amènera pas de baisse de performance en local puisque si tu louches un peu, Wayland c'est DRI2 (ou vice versa).
Bon il y aura quelques changement quand même: gestionnaire de fenêtre (simplifié puisque décoration faite cote client) intégré au serveur d'affichage: moins d'IPC: léger gain en performance, par contre la décoration coté client conduira a plus d'IPC entre le client et le serveur d'affichage quand on déplace une fenêtre, mais en cas de redimensionnement de fenêtre le résultat sera plus joli avec cependant un risque potentiel de saccade..
En réseaux, par contre la situation est beaucoup moins clair: les toolkits garderont-il le support d'X sur le long terme? Si ce n'est pas le cas, ça risque bien d'être le bazar..
[^] # Re: Comment ça marche ?
Posté par claudex . Évalué à 3.
Pourquoi? Si j'ai bien compris, le client a dessiné sa fenêtre dans le buffer, si on déplace la fenêtre, il n'a rien à faire.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Comment ça marche ?
Posté par reno . Évalué à 2.
Comment le serveur d'affichage saurait-il qu'il faut déplacer la fenêtre?
Il ne gère pas les décorations..
C'est le client qui le doit le lui dire, il n'y a pas a ré-envoyer le contenu de la fenêtre, mais il y a des IPCs en plus par rapport à une interprétation coté serveur.
Je pense que ça doit donner ça comme séquence avec décoration coté client: action souris --> kernel --> serveur d'affichage qui trouve le client correspondant et lui envoie l'évènement --> client qui interprète l'évènement comme "l'utilisateur veut déplacer ma fenêtre" --> envoit au serveur d'affichage une requête "déplace ma fenêtre".
Comparé à action souris --> kernel --> serveur d'affichage qui interprète l'évènement comme "l'utilisateur veut déplacer une fenêtre", le serveur déplace lui-même la fenêtre.
[^] # Re: Comment ça marche ?
Posté par claudex . Évalué à 5.
Sauf que certains serveur comme Kwin veulent gérer eux-même la décoration, donc il n'y aura pas ce problème.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Comment ça marche ?
Posté par liberforce (site web personnel) . Évalué à 2.
Il ne me semble pas, un des objectifs du projet, d'après Kristian Høgsberg:
Source: http://en.wikipedia.org/wiki/Wayland_%28display_server_protocol%29 (et aussi sa présentation au FOSDEM 2012)
[^] # Re: Comment ça marche ?
Posté par reno . Évalué à 4.
Il a dit ça oui, mais il ne faut pas l'interpréter comme tu le fait..
Wayland n'induit pas beaucoup de lag car il est "efficace" en local tout comme DRI2, mais il n'est pas magique si un programme est lent a régénérer l'affichage de sa fenêtre, il va y avoir des effets lors du redimensionnement..
Le test a été fait avec Windows7 ( http://thread.gmane.org/gmane.comp.freedesktop.wayland.devel/786 ), mais ça devrait être pareil avec Wayland: le redimensionnement de la fenêtre peut être saccadé si le programme est lent puisque tu attends que le programme ait fini d'afficher la fenêtre avec de montrer la nouvelle fenêtre..
Si tu fait le redimensionnement coté serveur, il n'y a pas de saccade car c'est le serveur qui va de manière autonome générer une nouvelle fenêtre, mais si le client est lent alors le résultat sera moche car par exemple le serveur générera la nouvelle fenêtre en ajoutant des bords a l'ancienne ou en tronquant l'ancienne image: moche mais fluide.
(Moche et fluide) ou (joli et saccadé): choisi ton camp, il n'y a pas d'alternative..
Enfin si il y en a une: utiliser une thread par fenêtre coté client à la BeOS ce qui devrait éviter qu'un programme soit lent à se ré-afficher.
[^] # Re: Comment ça marche ?
Posté par liberforce (site web personnel) . Évalué à 2.
D'après la réponse à ton lien, le comportement attendu sous Wayland est différent de celui de Seven:
Seven: La fenêtre est d'abord redimensionnée, puis le contenu est repeint. Si l'appli ne repaint pas assez vite, on voit des zones de l'arrière plan dans la fenêtre (moche et fluide)
Wayland: Le contenu de la fenêtre est d'abord repeint dans un buffer, puis la taille mise à jour (joli et saccadé).
[^] # Re: Comment ça marche ?
Posté par claudex . Évalué à 3.
Ce qui veut dire que sous Wayland, si une application ne répond plus, on ne peut pas la redimensionner?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Comment ça marche ?
Posté par liberforce (site web personnel) . Évalué à 3.
Aucune idée, mais ce que tu décris est apparemment le comportement actuel de Windows Seven:
[^] # Re: Comment ça marche ?
Posté par claudex . Évalué à 6.
L'intérêt, c'est pour les développeurs.
Je pense plutôt à des améliorations de fonctionnalités.
Ce n'est pas une couche d'abstraction supplémentaire. On remplace X, on écrit pas un truc au dessus X (qui est d'ailleurs un intérêt de Wayland, arrêter de contourner et d'ajouter des couches à X avec des trucs comme la composition)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Comment ça marche ?
Posté par ymorin . Évalué à 3. Dernière modification le 23 mars 2012 à 10:04.
Oui, je sais. On passe de trois couches avec quatre transferts (kernel -> serveur X -> client X -> server X -> compositeur), à deux couches avec 3 transferts (kernel -> wayland -> client -> wayland). Donc il y a une couche en moins, puisque wayland joue le rôle que le coule {serveur X , compositeur} jouait auparavant. C'est le corollaire à la loi de Ready qui s'applique, en effet :
À noter cependant, enlever une couche d'abstraction n'améliore pas forcément les performances ( A-implique-B n'est pas équivalent à B-implique-A ! ) ;-)
Hop,
Moi.
[^] # Re: Comment ça marche ?
Posté par claudex . Évalué à 3.
Si je me souviens bien, quelqu'un sur site expliquait qu'enlightment en framebuffer (sans X donc) était 5% plus performant. Il n'y a sans doute pas beaucoup d'amélioration de performance à attendre.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Comment ça marche ?
Posté par Charles-Victor DUCOLLET . Évalué à -1.
loi de jim ready ? là dessus google n'as pas été mon ami…
[^] # Re: Comment ça marche ?
Posté par ymorin . Évalué à 2.
https://linuxfr.org/news/elc-e-2010-un-compte-rendu-libre%C2%A0#14
http://elinux.org/images/5/5c/Deflate-virtualization.pdf
Hop,
Moi.
[^] # Re: Comment ça marche ?
Posté par zebra3 . Évalué à 4.
Ou pas, puisque Wayland aura moins de fonctionnalités que X, comme la transparence réseau.
Alors oui, ça pourra être ajouté après, mais il faut aussi comprendre que les gens n'ont pas forcément envie de perdres des fonctionnalités juste pour le bénéfice des développeurs.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Comment ça marche ?
Posté par claudex . Évalué à 3.
En même temps, le basculement ne devrait pas se faire trop vite. Je ne pense pas que ce soit une bonne idée avant au moins 2 ans. Il faudra voir à ce moment là.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Comment ça marche ?
Posté par Gui13 (site web personnel) . Évalué à 3.
Je me réponds à moi même: preuve que c'est un peu dommage, ils ont un exemple qui propose un client en HTML, et du coup t'es obligé de passer par un CGI à travers lighttpd, ce qui est pas optimal.
Si ta socket est directement en INET (quitte à en avoir 2, une UNIX pour les IPC et une INET pour les RPC), t'as juste à implémenter dans le browser du client le WebSocket qui va bien.
Bref, un projet à suivre.
[^] # Re: Comment ça marche ?
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Avec socat, on doit pouvoir s'en sortir ;-)
[^] # Re: Comment ça marche ?
Posté par thierryg35 . Évalué à 2.
Oui je confirme que ABUS est orienté embarqué pour un usage local via des sockets UNIX.
[^] # Re: Comment ça marche ?
Posté par thierryg35 . Évalué à 2.
Sinon, pour répondre à la connexion sur réseau local, comme je le précisait, le but est justement d'avoir cette orientation embarqué ce qui a été la contrainte la plus importante (pas de daemon, faible consommation de CPU & mémoire, moins de changement de contextes, …
Une passerelle est cependant possible comme je le précisait via lighttp et un plugins fcgi via des échanges HTTP(s)/json RPC.
Abus a vu démarré son développement en fin d'année dernière et sort aujourd'hui dans une version stable.
[^] # Re: Comment ça marche ?
Posté par Gui13 (site web personnel) . Évalué à 4.
Ouais mais justement, sur de l'embarqué, je pense que le coût de lighttpd est très supérieur (CGI = un nouveau processus pour répondre à chaque requête) à celui d'ouvrir une socket INET.
D'autre part, le choix d'utiliser JSON-RPC vous place tout de suite sur les rails d'une compatibilité native avec un navigateur web, qui fait tourner du JSON dans tous les sens. Ce serait dommage de vous priver d'une prise en charge native de l’interfaçage avec l'extérieur.
Mais comme tu le précise, le projet est jeune, et franchement il me paraît super intéressant (bien plus que msgpack par exemple, qui multiplie les bindings mais qui n'est jamais sorti en stable).
Bravo!
[^] # Re: Comment ça marche ?
Posté par jeberger (site web personnel) . Évalué à 2.
Attention : fcgi ≠ cgi ! Dans le premier, il est possible de réutiliser un même processus pour plusieurs requêtes.
Mais sinon, c'est clair que je ne suis pas convaincu par le choix de JSON : rien que le coût de codage / décodage des données va bouffer plus que ce qui est économisé en se débarrassant du broker…
[^] # Re: Comment ça marche ?
Posté par barmic . Évalué à 2.
Tu pense à quoi comme alternative ? Des données non structurées ou une serialisation binaire ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Comment ça marche ?
Posté par Michaël (site web personnel) . Évalué à 5.
La sérialisation par S-expressions (expressions Scheme) donne un format texte portable, et la lecture ou l'écriture sont très peu complexes.
[^] # Re: Comment ça marche ?
Posté par jeberger (site web personnel) . Évalué à 0.
Sérialisation binaire genre messagepack ou, justement, dbus.
[^] # Re: Comment ça marche ?
Posté par totof2000 . Évalué à 0.
XML ?
[^] # Re: Comment ça marche ?
Posté par Gui13 (site web personnel) . Évalué à 2.
C'est le parti pris de A-Bus, ils ont choisi d'implémenter quelque chose qui est compatible avec la norme JSON-RPC.
En terme de performances c'est très probablement pas le meilleur, mais en terme d'interopérabilité, je pense que c'est le bon choix.
Au boulot on commence à passer certaines de nos APIs "binaires" vers du JSON parce que ça apporte énormément de flexibilité.
D'une part parce que la compatibilité avec un browser est pratiquement gratos, ensuite parce que le fait d'avoir des paramètres nommés permet d'ajouter/retirer des paramètres très simplement. Comparé à du SOAP, je le trouve aussi plus simple à débugger, car tu peux coder un test unitaire en quelques minutes en Javascript sous NodeJS ou un browser.
[^] # Re: Comment ça marche ?
Posté par DerekSagan . Évalué à 1.
Vu le code source en lien ci-dessous, ça marche avec des sockets Unix:
http://code.google.com/p/abus/source/browse/trunk/abus/sock_un.c
Cela dit c'est faisable aussi sans sockets, avec d'autres méthodes, qui ont aussi leurs défauts (plein ont été citées plus haut, j'en ajoute une pour le fun: les IPC System V: mémoires partagées, sémaphores, files d'attentes).
# Petite question
Posté par barmic . Évalué à 2.
Je ne connais que DBus (si on oublie les ESB Java), il y en a d'autres ?
J'ai l'impression que faire le chemin inverse est bien meilleur d'un point de vu qualitatif : créer un logiciel pour l'embarquer et le faire venir sur desktop. C'est par exemple ce qui commence à se faire pour la libc, sous Debian (et d'autres) si je ne m'abuse.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Petite question
Posté par Misc (site web personnel) . Évalué à 5.
Dans mon souvenir, l'eglibc est un fork de la glibc, et surtout parce que Ulrich Drepper n'est pas super diplomate ( genre, "arm, c'est merdique", etc ).
Et j'ai pas le sentiment qu'on retrouve beaucoup d'outil de l'embarqué ( busybox, ulibc, framebuffer ) vers le desktop, à part java ( qui je rappelle à la base, vient du projet oak dans les années 90 )
[^] # Re: Petite question
Posté par thierryg35 . Évalué à 4.
il y en a pas mal et sans en faire un listing complet, il y a Corba, dbus, com+, dcom, DEC, ICE, XML-RPC, …
http://en.wikipedia.org/wiki/Remote_procedure_call
[^] # Re: Petite question
Posté par thierryg35 . Évalué à 3.
Je voulais préciser que ce développement ne se voulait pas décribiliser DBUS mais plutôt d'offrir une alternative aux plateforme GNU/Linux embarqué pour qui chaque ressources cpu, mémoire, IT comme les changement de contexte, accès aux I/O, …. compte.
A ce jour Abus est livré sous la forme d'une librairie dynamique & statique incluant des fonctionnalités json. Le développement offre aussi une cohérence avec pkgconfig via des métadata (abus.pc).
Si des développeurs sont intéressés pour collaborer au développement ou bien des utilisateur pour augmenter le nombre de cas d'utilisation.
[^] # Re: Petite question
Posté par Gabin . Évalué à 0.
Et pourquoi ça ne conviendrait pour le "desktop" cette contrainte?
[^] # Re: Petite question
Posté par thierryg35 . Évalué à 2.
Elle le peut tout à fait mais ce sont avant tout des contraintes que l'on retrouve dans l'embarqué et après comme je l'indiquait c'est transposable aux desktops.
# Bindings Python ?
Posté par Anonyme . Évalué à 2.
Python pour de l'embarquer ? Empreinte mémoire et processeur faible ? N'est-ce pas un peu contradictoire ?
[^] # Re: Bindings Python ?
Posté par PhE . Évalué à 2.
C'est de moins en moins vrai.
Et puis c'est l'intérêt du binding qui permets d'avoir la partie critique (en vitesse et empreinte mémoire) écrite en C et le reste dans un langage de haut niveau (moins "coûteux" en développement).
[^] # Re: Bindings Python ?
Posté par thierryg35 . Évalué à 1.
j'ai plus pas mal de fois des projets embarqué qui se débrouillais assez bien avec du bytecode, un garbage collector intégré, et toute la panoplie d'un langage objet.
Bref, abus n'a pas été écris en python mais pourra être utiliser dans ce langage tout en étant écrit en langage C, langage permettant une gestion de la consommations mémoire moindre.
# 0MQ ?
Posté par PhE . Évalué à 7.
Quel intérêt par rapport à une librairie comme 0MQ ?
[^] # Re: 0MQ ?
Posté par thierryg35 . Évalué à 1.
he bien c'est un développement alternatif similaire qui s'est avant tout inspiré de dbus.
il n'y a certes pas toutes fonctionnalités de part sa jeunesse mais cela à pour intérêt d'offrir une alternative viable puisque ce bus est déjà utilisé avec succès dans un développement commercial.
[^] # Re: 0MQ ?
Posté par M . Évalué à 3.
D'autant plus que de mémoire OMQ permet différent type de transport (entre thread, entre processus et entre plusieurs machine).
# Licence
Posté par M . Évalué à 2.
Pourquoi avoir choisi comme licence la gpl ?
Ca rend le truc peu utilisable dans l'industrie : on peut vouloir avoir sur le bus des logiciels proprio.
Il me semble que libdbus a une licence plus permisive.
Sinon ca aurait été bien d'avoir plus d'argument sur pourquoi développer encore un autre bus embarqué (a croire que chacun fait le sien chez lui sans regarder pourquoi les existants sont délaissé) et pourquoi avoir fait ce design.
[^] # Re: Licence
Posté par Larry Cow . Évalué à 2.
http://xkcd.com/927/
[^] # Re: Licence
Posté par thierryg35 . Évalué à 1.
heu non, une comparatif complet a été effectué mais peu sont dédié embarqué en respectant ses contraintes.
Sans les décribiliser, ce sont aussi souvent de gros développement avec une API qui vont au déla d'un usage embedded.
Abus ne s'est pas voulu tout remplacer ou réinventer mais plutôt founrnir un tiny librairie qui certes fait un minimum de choses mais qui le fait bien en tenant compte de ses contraintes.
[^] # Re: Licence
Posté par thierryg35 . Évalué à 2. Dernière modification le 23 mars 2012 à 10:44.
en fait il avait récemment changé de licence pour prendre la lgpl.
j'aurais préféré BSD ou MIT qui est plus permissive.
cela permet au moins de linker avec abus sans contamination.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.