Délaissé depuis juin, mon blog était très bien triste de ne plus parler d’embarqué. Voici donc quelques informations intéressantes dont je voulais parler. Je suis pas mal en retard ! Mais ce n’est pas grave !

Donc en vrac !

• Open Silicium sort son numéro 3, toujours aussi intéressant
• Buildroot a sorti sa version 2011.05. J’ai oublié il y a quelques mois de traiter mon dossier de mails de listes de diffusion. L’annonce de sortie s’est perdue dans mes plusieurs milliers de mails que j’ai aujourd’hui en attente. Dès que l’on arrête de consulter au fur et à mesure ces listes un peu trop prolifiques … c’est le début la fin !
• Le projet Armadeus a sorti la V4 de son système (voir LinuxFr à ce propos)
• La Freedom Box Foundation, dont je parlais il y a 6 mois donne des nouvelles de son projet. On voit que ça bouge, c’est chouette
• Oh, et puis un article intéressant sur les fichiers MLO pour les bootloaders de type X-loader

Sinon, je me suis lancé dans le développement d’un petit projet open source , dont je devrais parler bientôt ici. Je me cherche une licence en ce moment. J’ai repris un de mes anciens projets, sur l’enregistrement de flux SHOUTcast, que j’ai recommencé from scratch. C’est fou ce que ça va plus vite après quelques années d’expérience supplémentaires

Je me suis attelé récemment à la mise en place d’un mass storage (FAT32) sur un device Linux grâce au gadget file storage (g_file_storage), compatible avec Windows, Mac et Linux ! Hé bien, c’est un peu de la tambouille magique pour rendre ça compatible entre OS. Hélas, la documentation que l’on retrouve sur Internet ne précise pas forcément les étapes pour faire fonctionner le mass storage sous tous les OS. En fouinant bien j’ai fini par trouver les étapes à suivre pour mettre ça en place ! C’est plus une question du bon argument à spécifier à la création de la partition, mais au final on gagne du temps quand on le sait dès le départ ! Parce qu’aller fouiner dans le code source du driver pour voir comment ça marche c’est cool, mais un poil prise de tête. (encore que mine de rien c’est plutôt bien documenté)

Voici les étapes :

Préparation du kernel

• Prendre un kernel bien frais !
• Activer le “File-backed Storage Gadget” (USB_FILE_STORAGE) dans la catégorie USB support. Dans mon cas j’ai choisi de le mettre en module externe.
• recompiler la bête
• Et en attendant, préparons la partition de mass_storage.

Préparation de la partition

Jusque là, je n’ai réussi qu’à générer des partitions puissances de 2 au niveau de la taille. Avec des unités d’allocation de 4 Ko (par défaut), il suffit de changer le nombre de têtes (1, 2, 4, …) pour avoir respectivement des mass storage de (4, 8, 16Mo, …) Je n’ai pas encore complètement compris entièrement le fonctionnement pour tenter de sortir des clous avec des partitions exotiques (genre 7Mo si c’est envisageable). Si quelqu’un a l’information, je suis preneur Parce que je me perds un peu avec cette ratatouille de Linux / Windows qui n’ont pas les mêmes unités…

Bref, dans cet exemple je me base sur un mass storage de 4 Mo. Mais pour augmenter la taille de celle-ci, il suffit de changer la valeur du count dans la commande dd qui va suivre, puis le nombre de têtes dans le fdisk. Le max était 255 têtes, soit les 1020 Mo max du FAT32 pour des unités d’allocation de 4 Ko

Créons donc notre périphérique à partir du néant !

dd bs=1M count=4 if=/dev/zero of=mass_storage.img

Puis lançons fdisk.

$ fdisk mass_storage.img
Le périphérique ne contient pas une table de partitions DOS ou Sun, SGI, OSF valide
Création d'une nouvelle étiquette DOS avec id de disque 0x3a4a9ca1.
Les modifications restent en mémoire jusqu'à ce que vous les écriviez.
Après quoi, bien sûr, le contenu précédent sera irrécupérable.

AVERTISSEMENT: fanion 0x0000 non valide dans la table de partitions 4, sera corrigé par w(écriture)
Vous devez initialiser cylindres.
Vous pouvez faire cela depuis le menu des fonctions avancées.

WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
switch off the mode (command 'c') and change display units to
sectors (command 'u').

Commande (m pour l'aide): x

Commande pour experts (m pour de l'aide): s
Nombre de secteurs (1-63, par défaut 63): 8
AVERTISSEMENT: initialisation du décalage de secteur pour compatibilité DOS

Commande pour experts (m pour de l'aide): h
Nombre de têtes (1-256, par défaut 255): 1

Commande pour experts (m pour de l'aide): c
Nombre de cylindres (1-1048576): 1024

Commande pour experts (m pour de l'aide): r

Commande (m pour l'aide): n
Commande d'action
e   étendue
p   partition primaire (1-4)
p
Numéro de partition (1-4): 1
Premier cylindre (2-1024, par défaut 2):
Utilisation de la valeur par défaut 2
Dernier cylindre, +cylindres or +taille{K,M,G} (2-1024, par défaut 1024):
Utilisation de la valeur par défaut 1024

Commande (m pour l'aide): t
Partition sélectionnée 1
Code Hexa (taper L pour lister les codes): b
Type système de partition modifié de 1 à b (W95 FAT32)

Commande (m pour l'aide): p

Disque mass_storage.img: 0 Mo, 0 octets
1 têtes, 8 secteurs/piste, 1024 cylindres
Unités = cylindres de 8 * 512 = 4096 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Identifiant de disque : 0x3a4a9ca1

Périphérique Amorce  Début        Fin      Blocs     Id  Système
mass_storage.img1               2        1024        4092    b  W95 FAT32

Commande (m pour l'aide): w
La table de partitions a été altérée!

AVERTISSEMENT: si vous avez créé ou modifié une partition DOS 6.x,
svp consulter les pages du manuel de fdisk pour des informations
complémentaires.
Synchronisation des disques.

Et si l’on souhaite consulter les informations de notre partition :

$ fdisk -l mass_storage.img
Vous devez initialiser cylindres.
Vous pouvez faire cela depuis le menu des fonctions avancées.

Disque mass_storage.img: 0 Mo, 0 octets
1 têtes, 8 secteurs/piste, 0 cylindres
Unités = cylindres de 8 * 512 = 4096 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Identifiant de disque : 0x3a4a9ca1

Périphérique Amorce  Début        Fin      Blocs     Id  Système
mass_storage.img1               2        1024        4092    b  W95 FAT32

Pour accéder au device, on doit alors préciser à quel offset se placer pour travailler avec. Pour ça nous devons calculer la taille du premier cylindre. Soit :
offset = cylindres de 8 * 512 = 4096 octets (indiqué par la commande p du fdisk ou fdisk -l)

losetup -o 4096 /dev/loop0 mass_storage.img

Et on créé un magnifique système de fichiers FAT32 appelé “storage” :

mkdosfs /dev/loop0 -n storage

Si vous voulez vous pouvez monter votre mass storage et bidouiller dedans :

mount -t vfat /dev/loop0
...
umount /dev/loop0

puis on démonte le périphérique virtuel.

losetup -d /dev/loop0

Chargement du mass_storage

Une fois que votre kernel est en place sur votre système, il n’y a plus qu’à placer le fichier mass_storage.img sur le système embarqué et de charger la partition :

insmod g_file_storage.ko file=/tmp/mass_storage.img stall=0

stall=0 est l’option magique qui fait que le mass_storage fonctionne sous Windows sans mouliner à l’infini en attendant une détection du filesystem. (boolean to permit the driver to halt bulk endpoints)
On peut également jouer avec l’option ro pour mettre le mass storage en read only ou non. De façon générale on peut retrouver de la doc sur le driver dans le kernel : drivers/usb/gadget/file_storage.c

Et voilà, en branchant votre device sur n’importe quel OS, il sera reconnu comme disque de mass storage appelé “storage” Héhé !

Et pour la route, voici les partitions FAT32 finales (vides) :

• version 4Mo
• version 8Mo

Cela faisait quelques temps que je souhaitais rédiger une documentation sur D-Bus et ses concepts (en français). Je n’ai pas trouvé énormément d’informations sur lefonctionnement détaillé de ce Bus quand j’en avais besoin. Du coup, je me suis lancé dans la rédaction d’un tutoriel pour les personnes qui se retrouveront tôt ou tard dans le même cas que moi. Et puis ça me sert aussi de gros aide mémoire Vous pouvez consulter l’article sur developpez.com, mais également au format pdf.

D-Bus est un système de communication inter-processus initié en 2002 offrant un moyen simple de dialoguer entre applications. Aujourd’hui il est présent sur de très nombreux projets. Il fait partie intégrante d’Ubuntu, et sait être assez obscur pour les personnes souhaitant l’utiliser ou le comprendre. Cet article s’adresse aux personnes souhaitant comprendre le fonctionnement de D-Bus et éventuellement mettre en place une architecture logicielle basée sur ce bus.

Introduction

I-A. Qu’est-ce que D-Bus ?

I-B. Projets utilisant D-Bus

• Gnome
• MeeGo, anciennement Maemo / Moblin
• Android
• Skype
• Telepathy
• Evolution
• Pidgin
• Nautilus
• Connman
• network-manager
• HAL
• …

• à Nautilus de lancer un fichier multimedia via Rhythmbox au passage de la souris sur l’icone du fichier.
• à Pidgin d’afficher des popups de notification via Gnome à la réception de messages.
• à Evolution d’afficher des popups de notification via Gnome en cas de réception d’email.
• à Network-manager de gérer dans Gnome l’icone de gestion du réseau en haut à droite de l’écran

II. D-Bus : Les concepts

• Une bibliothèque, libdbus, permettant aux applications de communiquer entre elles.
• Un exécutable dbus-daemon basé sur libdbus, dont le rôle est de créer le support de communication entre les processus. Le daemon va s’occuper de router et acheminer les messages vers un ou plusieurs processus connectées au bus.
• Des wrappers et bindings permettant de travailler avec certains langages ou framework particuliers. Il existe des bindings pour le C et la glib, le C++ et le framework QT, Python, etc. A cela s’ajoute une API low-level en C permettant de créer ses propres bindings.

La connexion (sockets sur le schéma) peut prendre différentes formes :

• Unix Domain Sockets (IPC Sockets)
• launchd sous Mac OS X
• TCP/IP sockets

Il s’agit d’un protocole binaire, non textuel, qui s’affranchit donc des problèmes de sérialisation et de parsing de données formatées tel que le XML. On gagne donc en vitesse. (Hélas je n’ai pas eu l’occasion de tester et mesure cet aspect). Si vous êtes courageux, vous pouvez retrouver les spécifications de D-Bus sur le site de freedesktop.

D-Bus offre deux types de bus :

• Le bus session, il est utilisé pour la communication au sein d’une session utilisateur. Plus particulièrement au sein d’une session graphique de X. Il est créé à l’ouverture de session de l’utilisateur et perdure tant qu’elle est ouverte.
• Le bus système, comme son nom l’indique est dédié au transport d’information système bas niveau telles que les events kernel sous Linux, les notifications de connexion à un réseau, le (dé)branchement d’un périphérique USB, le statut de la batterie, etc. Des messages qui concernent donc tous les utilisateurs connectés au système. N’importe quel processus est en mesure de se connecter au bus système. Cependant, cette instance de bus possède une couche de sécurité autorisant ou refusant les messages qu’on lui demande de transmettre. A noter, que seul un seul bus système peut fonctionner à la fois. Le bus système est créé au démarrage du système dans une distribution de type Ubuntu.

Rien ne nous empêche de connecter une application à plusieurs bus. Par exemple à plusieurs bus session et au bus système. On peut par exemple séparer plusieurs bus de session pour des questions de sécurité. Mais nous aborderons la notion de sécurité un peu plus loin.

Connexions multiples d'un processus

Pour information, je déconseille fortement de tenter un /etc/init.d/dbus restart dans une session Ubuntu. Le résultat est juste catastrophique pour votre session. Vous n’avez plus qu’à redémarrer votre session !

Il existe aujourd’hui de nombreux systèmes de bus. D-Bus se démarque par sa conception orientée communication entre applications d’une session de type « Desktop », mais aussi pour la communication entre le Desktop et le système d’exploitation. D-Bus peut très bien être utilisé pour des systèmes n’ayant pas forcément de partie graphique, ni d’aspect « Desktop ». C’est à dire qu’il est parfaitement envisageable d’utiliser D-Bus en embarqué pour faire dialoguer ses applications entre elles.

Les mécanismes de D-Bus ne se résument pas qu’à une simple ouverture de socket entre le processus et le daemon. D-Bus permet d’identifier de façon unique les services qu’expose une application sur le bus. Rentrons dans les détails !

II-A. Messages

Il existe différents types de messages :

• les signaux
• les méthodes
• les messages d’erreur

Les signaux sont des notifications d’événements. Le signal est à sens unique et n’attend pas de retour. Son expéditeur ne précise pas le destinataire du message. Plusieurs processus peuvent s’abonner à ce signal. De plus, il peut contenir des paramètres.

Les méthodes permettent à des applications d’invoquer les méthodes d’objets distants. Les méthodes peuvent êtres invoquées avec des paramètres. Ces dernières peuvent être synchrones ou asynchrones et surtout en mesure de remonter de l’information à l’appelant en renvoyant un ou plusieurs paramètres (qui restent optionnels).

Les messages d’erreur offrent des exceptions dans le cas d’invocations de méthodes.

Du fait que D-Bus est un mécanisme de communication inter-processus, ce dernier supporte nativement plusieurs types pour les données échangés sur le bus (boolean, int32, string, …). D-Bus gère également des containers pour ces types : tableau, structure, dictionnaire et variant. Pour une liste exhaustive, se référer aux spécifications de D-Bus. Toutefois l’utilisation du typage de données est intimement liée au « binding » choisi lors du développement de l’application. Ces points seront abordés plus en détail dans de futurs articles.

II-B. Services

Un processus enregistre un service auprès du daemon D-Bus. Tous les clients souhaitant utiliser ce service vont pour cella créer un proxy (voir après). Lorsque des clients vont appeler des méthodes de l’objet du proxy, ce dernier va convertir ces méthodes en appels D-Bus qui sont reçus et exécutés par le processus qui a enregistré le service.

De plus, D-Bus fournit un mécanisme capable de démarrer automatiquement des applications à partir d’un simple appel. Une application peut exposer des services sur un bus. Si un des services est demandé par un autre processus, alors D-Bus est en mesure de démarrer l’application pour avoir accès au service en question.

Prenons l’exemple du service org.gnome.Rhythmbox sous Linux (lecteur multimédia d’Ubuntu). Il est possible de lui demander de lire une musique, voir de lire la suivante dans une liste de lecture, la stopper, etc. Tout cela par D-Bus. Si un appel D-Bus demande de lire une musique, et que le service Rythmbox n’est pas enregistré sur le Bus, alors, il va être automatiquement lancé et le message en question sera transmis à Rythmbox une fois que ce dernier sera opérationnel. Toutes ces étapes sont transparentes pour le processus à l’initiative de l’appel.

Nous pourrons voir un peu plus loin un exemple d’utilisation de Rythmbox par Dbus en ligne de commande.

Généralement, la plupart des applications utilisant D-Bus sont définies commes services. Sous Linux, la liste des services est située dans le dossier /usr/share/dbus-1/services. On y retrouve notamment à l’intérieur le nom du service et le binaire à démarrer à l’appel du service.

II-C. Objets

Chaque message D-Bus possède une source et une destination. Ces adresses sont définies par des « object paths ». Chaque processus connecté à un bus peut avoir enregistré un ou plusieurs objets. Les messages sont alors envoyés entre objets, mais pas directement par les applications.

Discussion entre deux applications sur D-Bus

Le PATH d’un objet est similaire à celui d’un filesystem UNIX, par exemple un objet pourrait être nommé /com/developpez/exemple/objetDBus. Il s’agit là d’une convention de nommage, nous sommes libres de créer des PATH de notre choix.

D-Bus permet ainsi aux applications d’exporter leurs objets et leurs fonctionnalités en tant que méthodes, que les applications peuvent utiliser pour communiquer entre elles. Elles utilisent pour cela les messages D-Bus.

Si l’on fait une comparaison avec un programme écrit en C++ qui implémente un service réseau, alors le nom du bus est l’hostname de la machine exécutant le programme. L’object path peut alors être vu comme un pointeur d’objet C++

II-D. Interfaces

D-Bus utilise également le principe d’interfaces, ce qui autorise l’utilisation d’un même nom de méthode plusieurs fois au sein d’un objet pour différents contextes. C’est une sorte de “namespace” pour les noms de méthodes, un groupe de méthodes et de signaux.

Si l’on reprend notre analogie au C++, l’interface peut être vue comme une classe C++

On peut prendre l’exemple de l’interface org.freedesktop.Introspectable qui permet aux instances d’objets de récupérer la description d’un objet (interfaces, signaux, méthodes et mêmes propriétés) et donc de faire ce que l’on appelle de l’introspection sur le bus. Très pratique ! (je ne vais pas plus loin, c’est juste un exemple. Vous avez plus d’informations à ce sujet dans les spécifications.)

II-E. Proxies

Les proxies sont des éléments haut niveau dans D-Bus, utilisés par les bindings pour simplifier l’utilisation du protocole. Ils permettent d’accéder aux objets à distance tout en travaillant au sein de notre programme. L’utilisation sera plus ou moins transparente pour le développeurs suivant les bindings. Le binding Glib n’est pas le plus simple hélas, mais permet de comprendre eu peu plus en détail le fonctionnement de D-Bus. Le binding Java, par exemple ne fait pas de différence entre les objets et les proxies. On a alors l’impression de travailler directement avec un objet. Nous pourrons aborder cette petite différence dans les prochains tutoriaux relatifs aux différents bindings.

Il est intéressant de noter qu’un proxy (pour certains bindings comme la Glib) permet de travailler avec un objet distant même en cas de « déconnexion » de celui-ci. Les proxies se comportant de cette façon, gèrent une sorte de « failover ». La reconnexion à l’objet distant est alors transparente, ce qui est relativement pratique. Prenons l’exemple du fichier org.gnome.Rhythmbox.service :

[D-BUS Service]
Name=org.gnome.Rhythmbox
Exec=/usr/bin/rhythmbox

III. Fonctionnement et utilisation de D-Bus

Avec une installation clé en main classique, D-Bus se créé un script de démarrage dans /etc/init.d qui permet de démarrer et stopper le daemon. Tout est démarré de façon automatique et presque transparente pour l’utilisateur. Nous allons toutefois décortiquer les étapes de lancement de D-Bus.

Avant toute chose D-Bus ne nécessite pas beaucoup de dépendances, on peut librement choisir la dépendance à libexpat ou libxml2. Le package sous Ubuntu utilise expat par défaut, mais la recompilation nécessaire pour passer à libxml2 n’est pas bien méchante.

D-Bus arrive avec un lot d’exécutables :

• dbus-launch : permet de démarrer un bus session depuis un script shell
• dbus-cleanup-sockets : fait le ménage dans les sockets ouverts par des bus et qui ne sont plus utilisés.
• dbus-send : permet d’envoyer un message sur le bus depuis un script shell
• dbus-daemon : Le plus important, le daemon D-Bus
• dbus-monitor : Permet d’observer ce qui transite sur un ou plusieurs bus
• dbus-uuidgen : génère des uuids pour les sessions de D-Bus

et de fichiers de configuration par défaut (/etc/dbus-1/ sous Linux)

III-A. Lancement de D-Bus

Pour lancer D-Bus lorsqu’il n’est pas déjà lancé (attention, les distributions récentes le lancent au démarrage), la première chose à faire est de lancer :

dbus-uuidgen --ensure

qui va aller vérifier l’existence du fichier /var/lib/dbus/machine-id. S’il n’existe pas il va générer un nouvel uuid (un identifiant unique). Le comportement est similaire à la commande uuidgen. Attention toutefois, l’uuid généré n’est pas un uuid standard.

L’étape suivante est le démarrage du bus system :

/usr/bin/dbus-daemon --system

Il existe tout un lot d’options avancées à dbus-daemon que vous pouvez retrouver sur le man de celui-ci. A noter cependant, qu’écrire dbus-daemon –system revient à écrire l’option « –config-file=/etc/dbus-1/system.conf« , même chose pour –session avec « /etc/dbus-1/session.conf« 

Cela me permet alors d’introduire la notion de configuration de D-Bus. En effet, ce dernier est paramétrable grâce aux fichiers de configuration suivants

• /etc/dbus-1/system.conf
• /etc/dbus-1/session.conf

Ils permettent de préciser des limites de ressources, paramètres de sécurité, tailles de messages, timeout, … Je vous invite à consulter le man de dbus-daemon pour en savoir plus.

Le lancement d’une session est « légèrement » plus compliqué. Comme il peut y avoir plusieurs bus session, il faut être en mesure de distinguer sur quel bus nous allons discuter. Nous utilisons pour cela la commande dbus-launch. Celle-ci va alors lancer une instance de bus de session en définissant les variables d’environnement nécessaires pour que les futurs programmes soient en mesure de trouver le bus.

Il suffit alors de lancer la commande suivante

dbus-launch --sh-syntax

qui nous retourne ces quelques lignes sur la sortie standard

DBUS_SESSION_BUS_ADDRESS='unix:abstract=/tmp/dbus-pV37oOMDlR,guid=90f13303a628db51a40b63454d14b6e7'; export DBUS_SESSION_BUS_ADDRESS; DBUS_SESSION_BUS_PID=10440; DBUS_SESSION_BUS_WINDOWID=62914561;

dbus-launch fait tout simplement appel à dbus-daemon –session et se charge de définir les variables de session que nous avons là. DBUS_SESSION_BUS_ADDRESS nous permet alors d’identifier le bus que nous venons de créer (on y retrouve les information sur le socket ouvert ainsi que l’uuid du bus). Sans la variable DBUS_SESSION_BUS_ADDRESS de définie dans votre environnement, vous aurez le droit à une erreur.

J’utilise ici l’option –sh-syntax qui permet d’afficher les informations du bus sur la sortie standard à destination d’un shell de type sh. Il existe d’autres options de formatage : –csh-syntax, –binary-syntax, ou –auto-syntax. Car par défaut, dbus-launch écrit de simples clés/valeurs sur la sortie standard et ne les exporte pas.

Je vous invite à regarder les man de chacune de ces commande si vous souhaitez avoir accès aux options avancées. A noter que la commande dbus-cleanup-sockets permet de faire du ménage dans les sockets ouverts par les bus et qui n’auraient pas été fermés correctement (en cas de fermeture intempestive par exemple.)

Sur un système clé en main de type Ubuntu, tout est lancé automatiquement et le bus est intimement lié à la session de Gnome. Donc avec un Ubuntu fraichement démarré, nous avons les bus system et session qui tournent. Par conséquent, nous n’avons pas à nous soucier des variables d’environnement déjà définies au démarrage de la session.

III-B. Utilisation de D-Bus par l’exemple

Nous pouvons à présent nous intéresser à d’autres commandes déjà plus concrètes.

• dbus-monitor, comme son nom l’indique, permet à la façon “wireshark” d’observer ce qui transite sur le bus.
• dbus-monitor –system permet d’observer le bus system
• dbus-monitor –session permet d’observer le bus session

Sans paramètre donné, dbus-monitor observera le bus session.

Vous pouvez alors voir qu’au sein d’une session Ubuntu énormément d’information transite sur le bus. En observant le bus system, on peut remarquer que des informations transitent lorsque l’on branche ou débranche une souris par exemple.

Il est possible filtrer les messages en spécifiant le type, l’émetteur, l’interface, … Par exemple observer les signaux envoyés par l’objet org.gnome.TypingMonitor:

dbus-monitor type=signal sender=org.gnome.TypingMonitor interface=org.gnome.TypingMonitor

Ou pour espionner les signaux de Pidgins, nous pouvons utiliser la syntaxe suivante :

dbus-monitor type=signal interface=im.pidgin.purple.PurpleInterface

Les outils graphiques :

• d-feet
• bustle
• DBusExplorer
• dbus-inspector
• QDBusViewer

permettent également d’observer ce qui transite sur D-Bus et de communiquer avec les processus. Mais d’autres applications existent, comme dbus-daemon-proxy développée par Alban Créquy qui redirige tout le trafic D-Bus par TCP. Outil initialement prévu pour teléphone nokia N900, pratique pour débugger à distance.

Pour terminer, le plus intéressant, l’outil dbus-send. Cette commande permet tout simplement d’envoyer un message depuis un script shell, et va me permettre d’illustrer concrètement mes précédentes explications.

dbus-send attend au minimum les arguments suivants :

• le nom du destinataire
• l’object path
• le nom du message
• et dans certains cas le type de message est requis

Prenons quelques exemples sous Ubuntu

dbus-send --dest='org.gnome.Rhythmbox' /org/gnome/Rhythmbox/Player org.gnome.Rhythmbox.Player.next

envoie le message next au logiciel Rythmbox ce qui fait passer à la musique suivante

dbus-send --dest=org.freedesktop.PowerManagement /org/freedesktop/PowerManagement/Backlight org.freedesktop.PowerManagement.Backlight.SetBrightness uint32:25

réduit à 25% la luminosité de votre écran

dbus-send --print-reply --dest=org.freedesktop.PowerManagement /org/freedesktop/PowerManagement/Backlight org.freedesktop.PowerManagement.Backlight.GetBrightness

retourne la valeur de la luminosité de votre écran

dbus-send --type=method_call --dest=org.gnome.ScreenSaver /org/gnome/ScreenSaver org.gnome.ScreenSaver.Lock

verrouille votre écran

dbus-send --type=method_call --dest=org.freedesktop.PowerManagement /org/freedesktop/PowerManagement org.freedesktop.PowerManagement.Shutdown

éteint votre ordinateur

dbus-send --system --print-reply --dest=org.freedesktop.Hal /org/freedesktop/Hal/devices/computer org.freedesktop.Hal.Device.GetAllProperties

retourne toutes les propriétés de HAL (hardware abstraction layer), c’est à dire de votre matériel.

Etc.

IV. Gestion de la sécurité avec D-Bus

D-Bus a également été développé dans un soucis de sécurité lors de l’échanges de messages. Les politiques de sécurité de D-Bus permettent de spécifier qui a le droit de parler à qui, ce qui est réellement pratique.

La politique de sécurité de D-Bus se précise dans les dossiers :

• le dossier /etc/dbus-1/system.d pour le bus système
• le dossier /etc/dbus-1/session.d pour le bus session

Elle se présente sous la force de fichiers XML à placer directement dans les dossier cités précédemment. Peu importe le nom des fichiers, seul le contenu va jouer ici.

Voici un exemple très simple qui autorise l’utilisateur root à

• posséder l’objet com.developpez.exemple.ObjetA
• envoyer des messages à l’object com.developpez.exemple.ObjetA
• appeler l’interface com.developpez.exemple.ObjectInterface

<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"> <busconfig> <policy user="root"> <allow own="com.developpez.exemple.ObjetA"/> <allow send_destination="com.developpez.exemple.ObjetA"/> <allow send_interface="com.developpez.exemple.ObjectInterface"/> </policy> </busconfig>

Il est alors possible de restreindre les accès suivant les utilisateurs, mais surtout de dire qui a droit de parler avec qui et sur quelles interfaces. Pour des explications détaillées sur la configuration des politiques de sécurité, se référer au man de dbus-daemon.

Dans certains cas, la sécurité de D-Bus n’est pas suffisante, et peut être couplée à SELinux. SELinux apporte la possibilité de restreindre l’accès d’applications spéficiques à des services donnés. Je n’ai jamais eu l’occasion d’aller jusque là, mais sa configuration se fait grâce à la balise <selinux>. Pour plus d’information, se référer également au man ou à la documentation de Redhat.

V. Les avantages et inconvénients de D-Bus

V-A. Les avantages

• D-Bus est léger
• D-Bus est un simple bus partagé par tout le système. Ce qui offre la possibilité de faire communiquer énormément d’applications entre elles, qu’elles soient au niveau de la session X ou du noyau.
• D-Bus permet une communication synchrone/asynchrone.
• Dans certains cas (comme Telepathy), D-Bus peut-être utile pour faire cohabiter des programmes dont les licences seraient contaminantes si elles ne passaient pas par un bus intermédiaire.
• D-Bus est multiplateforme et présent sur les 3 OS principaux (Windows, Mac, Linux)
• D-Bus peut être détourné de son utilisation « desktop » classique et adaptée aux besoins des systèmes embarqués.
• D-Bus permet de travailler de façon modulaire et développer des applications découpées en briques communicantes. Une brique peut planter sans impacter les autres et se reconnecter au bus d’elle même sans que tout le système s’écroule.

V-B. Les inconvénients

• Suivant le binding choisi D-Bus peut-être contaminant du fait de sa license. Prenons l’exemple du binding glib, sous license GPL V2. Il peut être « embêtant » de lier un projet dont on ne souhaite pas publier le code métier sous license open source. Ce genre de désagrément sera abordé dans un futur article dédié au binding glib. Cependant il faut néanmoins bien prendre en compte la question des licenses lorsque l’on part sur des projets industriels avec D-Bus. Les très mauvaises surprises sont très vite arrivées.
• Selon le binding, l’apport de bibliothèques partagées assez lourdes peut-être assez problématique selon les projets. Pour des cibles de type embarqué par exemple, embarquer le binding glib et ses libdbus.so* n’est pas un choix à prendre à la légère et peut être même rédhibitoire selon les contraintes de ressources et de place.
• Je n’en trouve pas d’autres !

VI. Les différents bindings D-Bus

Il existe différents bindings D-Bus pour utiliser le protocole avec différents langages :

L’API C « low-level » de D-Bus existe pour créer de nouveaux bindings. La librairie permet de travailler de façon très bas niveau sur le protocole. Mais comme la documentation le précise « If you use this low-level API directly, you’re signing up for some pain. » « Si vous utilisez directement l’API bas niveau, vous vous engagez à souffrir »

Mais pour travailler avec des langages un peu plus haut niveau, des bindings existent pour les langages suivants. En C avec Glib et Vala, en Python avec dbus-python , en C++ avec dbus-cxx ou le module QtDBus de QT, mais aussi en Java, C#,enlightenment, Perl, PHP, Pascal, Ruby, Haskell, OCaml, Objective-C, …

VII. Conclusion

Aujourd’hui, une très grande part des applications GNOME et KDE utilise D-Bus comme support de communication. Les possibilités d’interfaçage sur de nombreux langages offre de de belles possibilités de développement multiprocessus. Si j’arrive à trouver le temps, je rédigerai un prochain article sur des bindings D-Bus en particulier, histoire d’illustrer encore plus mes propos. En attendant, si vous avez des questions, ou remarques, n’hésitez pas !

VIII. Remerciements

Je remercie beaucoup bizulk pour sa relecture méticuleuse et ses remarques constructives qui m’ont été très utiles.

IX. Bibliographie

• http://library.gnome.org/devel/platform-overview/stable/dbus.html.en
• http://www.ibm.com/developerworks/linux/library/l-dbus.html
• http://freedesktop.org/wiki/IntroductionToDBus
• http://dbus.freedesktop.org/doc/dbus-tutorial.html
• http://dbus.freedesktop.org/doc/dbus-specification.html
• http://www.redhat.com/magazine/003jan05/features/dbus
• http://www.unixgarden.com/index.php/programmation/decouvertes-et-experimentation-avec-d-bus
• http://www.linuxjournal.com/article/7744
• http://doc.ubuntu-fr.org/dbus
• http://www.linuxforu.com/teach-me/d-bus-the-smart-simple-powerful-ipc
• Sans compter la mailing-list de D-Bus

Petit aide mémoire à moi même, et pour les gens qui en auraient besoin un jour. Voici une fonction C bien pratique pour générer le hash md5 d’une chaîne de caractères en C. Il y a juste besoin de linker openssl (-lssl) lors de la compilation.

#include <stdio.h>
#include <openssl/md5.h>
#include <string.h>

int md5_hash_from_string (char *string, char *hash)
{
    int i;
    char unsigned md5[MD5_DIGEST_LENGTH] = {0};

    MD5((const unsigned char *)string, strlen(string), md5);

    for (i=0; i < MD5_DIGEST_LENGTH; i++) {
        sprintf(hash + 2*i, "%02x", md5[i]);
    }
    return 0;
}

int main()
{
    char string[255] = "Hello World";
    char md5_hash[2*MD5_DIGEST_LENGTH+1] = "";
    md5_hash_from_string(string, md5_hash);
    printf("%s\n", md5_hash);
    return 0;
}

Je viens de tomber sur un superbe documentaire qui explique l’histoire de la carte Arduino. Ça laisse rêveur !

Arduino The Documentary (2010) English HD from gnd on Vimeo.

CES 2011 - Las Vegas

Je suis rentré lundi dernier de Las Vegas, où se déroulait comme chaque année le CES. J’y étais pour le travail, sur le stand de Karotz pour la présentation du dit produit, sur lequel je travaille depuis un an déjà.

Nous étions donc au CES dès mardi matin à la recherche de notre petit stand. On a fini par le trouver au fin fond du labyrinthe de caisses et de cartons. Hélas il a fallu attendre le lendemain pour avoir enfin tout notre matériel et nos Karotz qui étaient bloqués à la douane … Mon routeur de secours prévu exactement pour ce cas a eu la bonne idée de griller lors de son branchement ! Gros FAIL ! Bref, je peux vous dire que l’arrivée du fenwick et de notre petite palette le mercredi après midi était un sacré soulagement ! Ouf !

CES avant l'ouverture	Stand Karotz
Arrivée des Karotz

Journée/soirée de taré à tout installer à la vitesse de la lumière et notre stand était tout beau et prêt à affronter la foule du jeudi. Le CES a en effet commencé particulièrement fort. Toute la journée (et les jours suivants) le stand n’a pas désempli. Evidemment, la journée n’était pas terminée à 18h, car j’ai dû aller installer notre second stand au ShowStoppers, salon plus privé avec des journalistes, en parallèle du CES. Bon alors, forcément, comme au CES, le wifi faut pas compter dessus (trop d’interférences entre stands)… Par chance, nos amis Karotz fonctionnent en Ethernet !

Et nous avons donc enchaîné sur une soirée de Karotz très productive.

Du monde au stand Karotz

Karotz au ShowStoppers

Et rebelote au CES jusqu’à dimanche ! En tant qu’exposant, le CES est juste complètement épuisant, mais nous avons déjà pu avoir quelques retour sur le web de notre présence au CES

• CES-2011-Karotz-The-Broadband-Bunny-Rabbit
• CES 2011 awards (qui nous décerne le « top product of CES 2011″ )
• Karotz Robotic Rabbit Demo: Reads Your Feeds, Plays Music, Looks Cute Doing It
• Consumer Electronics Show: Karotz, a bunny to do your bidding
• Karotz Debuts Upgraded Wi-fi Communication Rabbit
• Nabaztag rabbitputer evolves into Karotz compubunny
• Karotz: The New Nabaztag
• CES 2011: Karotz, the successor to Nabaztag
• …

Ce que je regrette c’est de ne pas avoir eu énormément de temps pour visiter le reste du CES et le ShowStoppers (que je n’ai absolument pas pu parcourir). J’ai pu faire un tour rapide au CES, mais j’aurais aimé en voir plus. Vis à vis du CES 2011, je n’ai rien vu de vraiment transcendant… Ne comprenant pas trop l’engouement pour la télé 3D que nous avions à toutes les sauces, j’ai passé mon chemin. Niveau tablettes, nous avions de quoi faire J’ai pu aller voir la Galaxy Tab, que nous avons déjà au travail. Je suis allé m’amuser avec la Google TV de Logitech. Encore une fois, rien de bien fantastique, c’est une set top box que l’on a depuis un paquets d’années en France, mais à la sauce Google quoi. J’ai souhaité bien du courage à la fille du stand pour lancer le produit en France

Google TV de Logitech

Google TV de Logitech

Bon, j’ai donc continué mon tour, j’ai pu revoir les robots que nous voyons depuis quelques années sur le net et dans les magazines spécialisés. C’était tout de même bien sympa de les tester ! J’ai pu également en voir de nouveaux !

Phoque Paro - Robot Therapy	Oh un robot trop meeugnon !
Le Robot Pléo	Un robot masseur
Un robot qui vous aide à faire votre régime

et j’en passe …

Mais je n’ai été réellement bluffé que par 2 trucs :

L’imprimante 3D MakerBot Industries (que j’avais déjà entrevue sur le net) mais avec une explication live c’est nettement plus classe. Il s’agit donc d’une imprimante 3D qui imprime ce que vous voulez en plastique, en chauffant de la matière première. Un modèle 3D en input, et zou on a un modèle 3D réel en quelques heures. C’est juste fantastique pour faire des prototypes. Pour $1225 c’est la fête du bricoleur ! Ils ont même poussé le vice à recréer un bonhomme légo pièce par pièce ! Woooot ! Bon c’est un peu cher je vous l’avoue. MAIS j’adore !!!

Makerbot l'imprimante 3D	Makerbot l'imprimante 3D
Un visage en 3D réalisé avec Makerbot	Quelques exemples de réalisations
Un perso lego articulé en 3D réalisé avec Makerbot

Et le proto de jouet d’Intel : qui montrait un proto d’interaction réel/virtuel entre jouets (légos) pour les enfants. Ça, j’aurais bien aimé l’avoir gosse ! En gros on pose un dragon légo sur une surface plane, ça commence à projeter des flammes devant le dragon. On l’approche d’une maison, et fiou elle prend feu. Mais comme un camion de pompier en légo n’est pas loin, il suffit de l’approcher et un jet d’eau sort de la lance et éteint la maison. En discutant avec le mec d’Intel il m’a expliqué que s’en était encore qu’à l’état de proto et qu’ils réfléchissaient à la façon de créer les interactions et surtout permettre au gens d’en créer. Snif pas pour tout de suite. Mais tellement de potentiel ! J’aime !

Le proto d'Intel

Mes impressions sont forcément biaisées, du fait de ne pas avoir pu tout parcourir au CES faute de temps

Donc voilà, CES 2011, salon bien épuisant ! En espérant pouvoir revenir l’année prochaine au CES 2012 avec un nouveau produit à présenter

Et pour la route, quelques photos de Las Vegas, parce que ces américains sont de grands malades !

Et voilà ! Depuis le temps que je cherchais à le faire ! Je viens de déménager mon blog (et ma flopée d’autres sites) sur mon nouveau serveur mutualisé. J’en avais marre d’administrer mon serveur dédié, car c’est du travail, et un métier … Mon truc c’est plutôt de créer des systèmes Linux, mais les administrer c’est moins fun ! C’est comme les légos quand j’étais enfant, ça devient moins marrant une fois que tout est construit.

Bref, juste pour dire que normalement je devrais :

• ne plus avoir de problème de Captcha
• et ne plus avoir de problème de mails capricieux qui envoient les notifications de commentaires un mois après.

J’en ai même profité pour passer sous WordPress 3.0.1.

Bref, tout est bien dans le meilleur des monde

J’ai mis à jour un certain nombre de plugins récemment, dont celui du CAPTCHA. On vient de me signaler qu’un message d’erreur bloquait la publication de nouveaux commentaires. Merci les mises à jours automatiques de WordPress !!

Je viens de corriger le problème On peut à nouveau écrire des commentaires. Si ça se reproduit, n’hésitez pas à me contacter.

Je suis tombé aujourd’hui sur un article très intéressant d’Ars Technica, relayé par Toolinux. La semaine dernière, à la conférence LinuxCon à Boston, les créateurs de MeeGo ont abordé les éléments qui différenciaient leur nouveau système de ceux existants sur le marché. En profitant pour annoncer la sortie du premier appareil sous MeeGo cette année, Thomas Miller (Nokia’s MeeGo Ecosystem Development head) a déclaré que l’appareil serait ouvert. Dans le sens où les utilisateurs seraient à même de modifier le software. Donc de quoi ravir les early-adopters.

Un des avantages notables de MeeGo, et pas des moindres, est que les constructeurs seront en mesure de participer au processus de développement du système de façon plus active. Ce qui fait donc la force du produit à mes yeux ! L’approche est différente de celle de Google Android qui est moins proche du Libre qu’on voudrait le croire. Les fondateurs de MeeGo montrent ainsi un peu du doigt la politique de Google Android, moins ouverte.

Mettant en avant la diversité des langages de programmation disponibles sur MeeGo, les créateurs de MeeGo ont également abordé le point de la distribution des applications. Les utilisateurs et développeurs auront la possibilité de disposer de plusieurs stores. Les fabriquant seraient également en mesure de bénéficier de leur propre de store basé sur le service AppUp d’Intel

Concernant le choix de QT comme framework par défaut, je vois déjà râler les gens qui critiquent le C++ et préfèrent des langages plus « facile d’accès ». Cependant, utilisant Android quotidiennement, j’ai légèrement le sentiment que l’Android Market devient de plus en plus pollué par les applications buggués, inutiles et faites à la va-vite. Je ne sais pas comment les stores de MeeGo seront gérés et agencés. Toutefois, je me demande si la décision d’utiliser QT ne serait pas à terme un gage de qualité (ne pas y voir un sentiment anti JAVA, mais plutôt anti développeurs du dimanche).

Idéalement, je rêverais beaucoup plus d’un système d’applications libres, améliorées par les utilisateurs et développeurs, plutôt qu’un système de magasin en ligne où les gens ne publient que leurs exécutables. Attention, je fais bien la distinction entre libre et gratuit. A vrai dire, l’aspect Libre d’Android ne transparaît pas du tout dans ses applications. Point que je trouve réellement intéressant chez MeeGo s’ils s’aventurent dans l’optique de l’ouverture.

Tout cela pour conclure que ces annonces illustrent une vision des choses bien différente de celle des concurrents actuels de MeeGo. Dans ce sens, c’est exactement ce qui se rapproche de ma façon de voir les choses. A ce titre, je pense que MeeGo aurait parfaitement sa place sur le marché, offrant des perspectives plus proches du Libre. J’ai maintenant juste hâte que le premier appareil sous MeeGo sorte

Je suis récemment tombé sur un projet complètement génial réalisé par un Allemand. Mêlant jeu vidéo et réalité virtuelle, l’idée est de télécommander une voiture dans un véritable circuit en carton le tout commandé par une borne d’arcade. Et bien sûr, géré par une carte Arduino ! Tiens, tiens !

L’idée est vraiment énorme. J’ai un gros projet similaire en tête depuis un moment déjà, je sens que je vais finir par m’y mettre. Déjà parce que cette vidéo m’a vraiment donné envie de me lancer pour de bon et ensuite parce que quelqu’un va finir par avoir la même idée que moi