Linux A-Bus, un autre bus dédié GNU/Linux embarqué

Posté par . Édité par Nÿco et baud123. Modéré par NeoX. Licence CC by-sa
37
22
mar.
2012
Linux

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 !

  • # C'est bien.

    Posté par (page perso) . Évalué à  5 .

    Les transports en commun c'est bon pour la planète.

    • [^] # Re: C'est bien.

      Posté par . É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 . É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 (page perso) . Évalué à  10 .

      Ça suffit, les jeux de mots, je trouve qu'il y a de l'A-Bus, là…

  • # Comment ça marche ?

    Posté par (page perso) . Évalué à  6 .

    Le lancement d'A-Bus a été lancé autour de l'idée de n'avoir aucun daemon

    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 (page perso) . É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 (page perso) . Évalué à  6 .

        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.

        Ça donne quand même vachement l'impression qu'ils reprochent à D-Bus d'utiliser des sockets…

        • [^] # Re: Comment ça marche ?

          Posté par (page perso) . É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:

          Serveur  <--- UNIX Socket 1 --> Broker <--- UNIX SOCKET 2 --> Client
          
          

          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:

          Serveur <--- UNIX --> Client
          
          

          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 . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 . É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 . Évalué à  2 .

                  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

                  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 (page perso) . Évalué à  3 .

                    C'est une simplification de l'architecture qui est visée pas une augmentation des performances.

                    « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                    • [^] # Re: Comment ça marche ?

                      Posté par . Évalué à  3 .

                      C'est une simplification de l'architecture qui est visée pas une augmentation des performances.

                      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:

                      Aucune couche d'abstraction supplémentaire ne permettra d'exécuter le logiciel plus rapidement.

                      Hop,
                      Moi.

                      • [^] # Re: Comment ça marche ?

                        Posté par . É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 (page perso) . Évalué à  3 .

                          plus d'IPC entre le client et le serveur d'affichage quand on déplace une fenêtre

                          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.

                          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                          • [^] # Re: Comment ça marche ?

                            Posté par . Évalué à  2 .

                            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.

                            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 (page perso) . É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.

                              « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                        • [^] # Re: Comment ça marche ?

                          Posté par (page perso) . Évalué à  2 .

                          mais en cas de redimensionnement de fenêtre le résultat sera plus joli avec cependant un risque potentiel de saccade..

                          Il ne me semble pas, un des objectifs du projet, d'après Kristian Høgsberg:

                          every frame is perfect, by which I mean that applications will be able to control the rendering enough that we'll never see tearing, lag, redrawing or flicker.

                          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 . É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 (page perso) . Évalué à  2 .

                              Le test a été fait avec Windows7, mais ça devrait être pareil avec Wayland

                              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 (page perso) . Évalué à  3 .

                                Ce qui veut dire que sous Wayland, si une application ne répond plus, on ne peut pas la redimensionner?

                                « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                                • [^] # Re: Comment ça marche ?

                                  Posté par (page perso) . Évalué à  3 .

                                  Aucune idée, mais ce que tu décris est apparemment le comportement actuel de Windows Seven:

                                  This zombie window responds to move and raise events, but not resize attempts.

                      • [^] # Re: Comment ça marche ?

                        Posté par (page perso) . Évalué à  6 .

                        Alors, dans ce cas, je préfère la vieille architecture performante, plutôt que la nouvelle simplifiée.

                        L'intérêt, c'est pour les développeurs.

                        Bon, sûr, à terme, la simplification vas potentiellement amener une amélioration des performance

                        Je pense plutôt à des améliorations de fonctionnalités.

                        Aucune couche d'abstraction supplémentaire ne permettra d'exécuter le logiciel plus rapidement.

                        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)

                        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                        • [^] # Re: Comment ça marche ?

                          Posté par . Évalué à  3 . Dernière modification : le 23/03/12 à 10:04

                          Ce n'est pas une couche d'abstraction supplémentaire.

                          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 :

                          Pour améliorer les performances, il faut supprimer des couches d'abstraction

                          À 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 . Évalué à  4 .

                          Bon, sûr, à terme, la simplification vas potentiellement amener une amélioration des performance

                          Je pense plutôt à des améliorations de fonctionnalités.

                          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 (page perso) . É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à.

                            « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: Comment ça marche ?

        Posté par (page perso) . É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 . Évalué à  2 .

      Oui je confirme que ABUS est orienté embarqué pour un usage local via des sockets UNIX.

      • [^] # Re: Comment ça marche ?

        Posté par . É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 (page perso) . É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 (page perso) . Évalué à  2 .

            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.

            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 . Évalué à  2 .

              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…

              Tu pense à quoi comme alternative ? Des données non structurées ou une serialisation binaire ?

              Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

            • [^] # Re: Comment ça marche ?

              Posté par (page perso) . É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 . É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 . Évalué à  2 .

    il en [des bus logiciel] existe un certain nombre

    Je ne connais que DBus (si on oublie les ESB Java), il y en a d'autres ?

    la plupart ce sont des bus issus du monde des desktops ayant été portés pour l'embarqué, sans aucune adaptation

    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.

    Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

    • [^] # Re: Petite question

      Posté par (page perso) . É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 . É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 . É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 . Évalué à  0 .

          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.

          Et pourquoi ça ne conviendrait pour le "desktop" cette contrainte?

          • [^] # Re: Petite question

            Posté par . É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 (page perso) . Évalué à  2 .

    Python pour de l'embarquer ? Empreinte mémoire et processeur faible ? N'est-ce pas un peu contradictoire ?

    Love, bépo.

    • [^] # Re: Bindings Python ?

      Posté par . É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 . É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 . Évalué à  7 .

    Quel intérêt par rapport à une librairie comme 0MQ ?

    • [^] # Re: 0MQ ?

      Posté par . É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 . É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 . É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 . Évalué à  2 .

      a croire que chacun fait le sien chez lui sans regarder pourquoi les existants sont délaissé

      http://xkcd.com/927/

      • [^] # Re: Licence

        Posté par . É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 . Évalué à  2 . Dernière modification : le 23/03/12 à 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 à ceux qui les ont postés. Nous n'en sommes pas responsables.