voici les premiers modèles alpha de la Raspberry Pi.

Raspberry Pi Alpha

20 % plus grands que les modèles finaux, qui seront de la taille d’une carte de crédit.

Eben Upton, le président de la Raspberry Pi foundation, nous présente la carte en vidéo, qui tourne dès à présent sous Debian.

Pour ceux que ça intéresse, un concours de création de logo a également été ouvert.

J’aurai donc participé à l’aventure Karotz sur toutes les étapes de sa vie (jusqu’à aujourd’hui en tout cas !). Une super expérience que de développer un produit de A à Z, de sa conception début 2010 à sa sortie en avril 2011, en passant par sa promo au CES à Las Vegas. Chouette sentiment que de retrouver à la Fnac et Virgin un produit sur lequel on a travaillé ! Aujourd’hui, je vois plus ce départ comme un tremplin pour moi, car je n’aurai jamais autant appris en si peu de temps qu’avec ce projet.

Je vais mettre un peu de côté le développement user space et me rapprocher beaucoup plus du kernel pour mettre un peu plus les mains dans le cambouis (et faire encore plus le geek \o/). Pas trop de répit après avoir quitté Mindscape le 1er août, car j’ai repris une semaine après chez Archos, où je travaille maintenant

Ce billet est surtout l’occasion de remercier tous les gens qui me proposent du travail. Malheureusement pour vous, je pense avoir trouvé chez Archos exactement ce que je cherchais et ne suis donc plus disponible. En tout cas, Merci !

A la clef, des cartes Mini2440, des tablettes Archos et du fun !

Ouvert aux étudiants et aux individuels, le concours se divise en deux parties.

• Dans un premier temps, le but est de faire fonctionner le système en le simulant sous qemu. Ce qui permet de gagner une carte Mini2440 et de passer à l’étape suivante. Les participants ont jusqu’à fin octobre pour gagner une carte.
• La finale se passe ensuite sur les cartes Mini2440. Où le but est cette fois d’optimiser au maximum le boot du système sur la plateforme choisie. Cette seconde phase se terminera fin décembre.

Les contraintes techniques se résument en quelques lignes :

Le système devra fonctionner avec un noyau Linux sur une carte Mini2440, obtenir une adresse IP par DHCP et l’afficher en grand dans une application graphique. Un bouton tactile devra également permettre de déclencher l’affichage du nom du ou des auteurs, ainsi que le nom d’équipe s’il y a lieu.

Le temps sera compté à partir du démarrage électrique (à froid) jusqu’à l’affichage graphique.

Il est possible d’optimiser le bootloader, le noyau et l’espace utilisateur (également appelé applicatif ou rootfs).

Donc, seule contrainte, utiliser Linux. En dehors de ça, libre aux participants de bidouiller/hacker à mort leur système pour arriver à leurs fins Le but est de se faire plaisir !

Juste besoin d’envoyer un email pour s’inscrire. Un Wiki a été mis en place, ainsi qu’un Forum et un channel IRC.

Je n’ai pas pu résister au défi, je me suis inscrit, en espérant que je trouverai le temps nécessaire pour faire tout ça !

Sur ce ! Au boulot !

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

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

• l’ELC 2011 à San Francisco
• l’Android Builders Summit 2011 à San Francisco toujours
• le FOSDEM 2011 à Bruxelles

Tout plein de vidéos super intéressantes.

Encore une fois, merci à eux Je peux continuer à me former sans prendre l’avion

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

#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;
}

Il y a eu donc une première table ronde sur Android avec des messieurs SSII, dont le monsieur embarqué Pierre Ficheux. Bon, au final rien de bien transcendant. Les points suivants ont été abordés :

• le marché d’Android et son émergence depuis quelques années/mois
• l’intégration d’Android sur de nouveaux devices
• l’utilisation (ou pas) d’Android par les industriels.
• l’ergonomie d’Android et sa comparaison avec les produits Apple. (soit dit en passant, ça taillait pas mal sur Apple, niark)
• la dépendance vis à vis de Google et la question de sécurité et de vie privée

Sinon je ne sais plus qui a dit ça dans les intervenants, mais j’ai bien rigolé lors de la comparaison d’Android et du HTML. Genre Android c’est l’équivalent du HTML pour les téléphones. Ahahah … !

Bref ce qui en sort c’est surtout qu’Android est un OS Mass Market pour le multimedia pour produits avec écrans. Dans le lot des intervenants, il n’y avait que 2 personnes avec un esprit un plus critique sur Android. Dommage que la discussion n’ait pas été plus loin sur les « inconvénients » d’Android, ça aurait été plus intéressant. Car le discours était plus de l’ordre « Android il est bien, Android il est gentil, Android c’est la solution universelle ! ». J’aurais bien aimé pousser la discussion sur ces inconvénients et avoir une table ronde plus objective. Mais bon d’un autre côté ils n’allaient pas inviter un intervenant MeeGo et un intervenant Apple dans le lot pour parler d’Android

Table ronde sur Android

Tiens, d’ailleurs ça devait être le moment où Pierre Ficheux a dit qu’Eclipse ça faisait pitié (quand on venait du vrai monde des gens qui utilisent QT) Je dis respect ! Dire ça à une table ronde sur Android entouré de fanboys Android :) Ahah !

Sinon en passant, vous pouvez retrouver la vidéo de la table ronde sur le site du Paris Android User Group. Bon bah il s’avère que je suis en plein dans le champ à plusieurs reprises (1min50). J’étais sur le siège d’à côté…

Seconde conférence

Seconde conférence intitulée « Terminaux mobiles et fuite de d’information », qui s’est transformée en « Architecture Android, les spécificités de l’OS » au dernier moment. Philippe Prados, a qui on doit le numéro hors série de Linux Magazine sur Android, nous a expliqué le fonctionnement d’Android. 30 min pour la présentation, dommage car pas facile de rentrer dans les détails. J’ai pu réapprendre le fonctionnement des Activities and co d’Android Mais bon ça restait intéressant, bien que très court. Enfin j’aurais bien aimé avoir la présentation « Terminaux mobiles et fuite de d’information ». Mais apparemment l’intervenant qui devait venir a eu un imprévu. Donc bah ça sera pour un prochain salon !

Troisième conférence sur OpenEmbedded

La troisième conférence était  intitulée « Linux sur ARM : ça ne date pas de 2010 OpenEmbedded, un framework pour des applications embarquées riches ». Pendant la conférence d’avant j’ai repéré un visage qui me disait quelque chose. J’ai fini par réaliser qu’il s’agissait de Christian Charreyre que j’avais vu 2 mois plus tôt au salon RTS Embedded Systems. FAIL pour le coup, le nom de la présentation n’était pas le même, mais le contenu l’était. Du coup, je me suis assuré que la présentation était identique, et j’ai plutôt opté pour un retour sur le salon.

Etonnemment je m’attendais à quelque chose de différent, plus orienté projets open source. Au lieu de ça, il y avait énormément de SSII/SSLL/SSLLL/and co. Il y avait bien sûr pas mal de stands d’associations relatives à toutes les distribs possibles et imaginables de Linux, un stand Gnome et un stand KDE côte à côte (fight !), l’April, de l’hébergeur et encore de l’hébergeur, pas mal d’associations d’utilisateurs et de développeurs, le stand du PAUG, et tout plein de stands de SSII

Il y avait Intel également qui présentait MeeGo et ses tablettes atom. J’ai attendu un moment avant de pouvoir discuter avec une des personnes du stand. J’ai été un peu violent avec la personne avec mes questions (pardooooon !), je lui ait demandé quels étaient les arguments que je pourrais utiliser pour choisir MeeGo au profit d’Android. Aie ! Question très méchante ! J’étais très intéressé par la réponse à cette question à vrai dire. Il m’a avancé les avantages de l’open source, de leur store multi-plateformes,  mais je suis déçu, je n’ai pas eu réellement d’argument béton pour choisir Meego plutôt qu’Android. Ce qui m’a fait un peu peur (enfin j’étais sur le stand Intel…) c’est que MeeGo n’a pas (plus?) réellement vocation à tourner sur ARM. Enfin il m’a annoncé clairement qu’avec le départ de Nokia le support des processeurs ARM était pas franchement leur priorité. Bon Intel prêche aussi pour sa paroisse ! Mais bon… Donc au final j’en tire une conclusion simple :

• Android = arm
• MeeGo = x86

Aussi simple que cela ? Hum, ça m’embête ! Je vais continuer à mener mon enquête pour déterminer si je dois choisir MeeGo ou Android pour les prochains produits sur lesquels je vais travailler.

Ah et puis marrant, j’ai croisé un professeur de lycée qui m’a reconnu à mon nom sur mon badge car il avait travaillé sur la carte fox et qu’il connaissait mon blog Huhu

Un éléphant PHP géant ! Cooool !

Ah oui ! Aussi, un truc qui m’a bien fait marrer ! Un stand Microsoft ! (désolé pour la photo crade)

Des guerriers courageux de chez Microsoft !

Pour conclure, je suis bien content de ce salon. Ne serait-ce que par simple curiosité, j’avais envie d’y aller. J’imaginais l’évènement un peu plus geek, au lieu de cela je suis tombé plus sur un salon très axé service. Les projets open source étaient représentés par des associations, et les sociétés qui les mettent en oeuvre placées à part. Je comprends le fonctionnement, mais je  ne m’attendais pas à ça.

Sinon j’ai pu grapiller bien du Linux Mag et de la revue en tout genre

Ah et puis … merci pour les autocollants Linux, ils ont fini collés sur le mac d’un de mes collègues

Prochain salon, les RMLL en juillet !

Il s’agit d’un système basé sur un processeur ARM11 à 700MHz et 128Mo de RAM. De la taille d’une clé USB, ils l’annoncent à un prix de £10 à £15 (soit 17€). Oui 17€ ! Même s’il ne s’agit peut-être là que du prix des composants cela reste réellement intéressant.

En voici les specs détaillées :

• 700MHz ARM11
• 128MB of SDRAM
• OpenGL ES 2.0
• 1080p30 H.264 high-profile decode
• Composite and HDMI video output
• USB 2.0
• SD/MMC/SDIO memory card slot
• General-purpose I/O
• Open software (Ubuntu, Iceweasel, KOffice, Python)

Le système Raspberry Pi avec un module caméra

Sachant ce que l’on peut faire avec un tel matériel, cela pourrait bien devenir un produit révolutionnaire pour la communauté de la bidouille et du DIY. Le prix est tellement bas que je me demande *vraiment* si ce communiqué est vrai et si le projet est économiquement viable. Si tel était le cas, on se retrouverait avec un Linux embarqué pour moins cher, voir le même prix qu’une Arduino… Oh ! j’en achète une caisse tout de suite !

Même si l’approche et beaucoup plus axée éducation, apprentissage de l’informatique en générale, et comme ordinateur low-cost du genre OPLC, je ne peux que voir l’avantage d’une telle carte de dev de type ARM à seulement 17€ pour le monde de la bidouille. A ce prix, il n’y a plus de limite aux possibilités d’une telle carte ! Imaginez le système Raspberry Pi couplé à une carte Arduino ! Pour moins de 50€ nous avons le système rêvé de tout hacker qui se respecte.

J’ai hâte !