Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

ADR-001 — IPC AirCom, refus de D-Bus comme transport principal

Statut : Accepté. Document fondateur immuable après ouverture publique.

Catégorie : Architecture (couche 2 — IPC).

Note de nomenclature (2026-05-31) : l’IPC d’Air, initialement nommé Conduit lors de la rédaction early-stage, a été renommé AirCom. Le contenu de cet ADR a été aligné sur ce nom, et le fichier lui-même a été renommé de ADR-001-conduit-fr.md en ADR-001-aircom-fr.md (avec mise à jour de tous les liens entrants) afin de ne pas laisser subsister l’ancien nom, source de confusion. Le numéro d’ADR (001) reste l’identifiant stable.

Contexte

D-Bus est, depuis sa première spécification en 2003, le mécanisme d’IPC standard de l’écosystème Linux desktop et, dans une large mesure, de l’écosystème serveur. Il est utilisé par systemd, NetworkManager, BlueZ, UPower, polkit, ModemManager, geoclue, accountsservice, les environnements GNOME et KDE, et la quasi-totalité des services freedesktop. Son rôle historique dans l’unification des communications inter-services sur Linux est réel et durable.

Cette décision n’est donc pas une critique générale de D-Bus. C’est un choix de transport pour les services Air natifs entre eux, qui s’inscrit dans un constat précis : les besoins d’Air en matière de sécurité capability-based, de performance sur matériel modeste, et de stabilité contractuelle sur dix ans (cf. ADR-012) ne sont pas couverts par D-Bus tel que conçu. Air reconnaît la place de D-Bus dans l’écosystème et continue à l’utiliser pour interopérer avec lui ; en revanche, Air n’utilise pas D-Bus comme transport interne pour ses propres services natifs.

Cette décision a été prise après examen des évolutions tentées de D-Bus (kdbus, bus1, dbus-broker) et après évaluation des IPC contemporains qui ont influencé la conception de AirCom (XPC sur macOS, Cap’n Proto, FIDL sur Fuchsia, Mojo sur Chromium, Binder sur Android).

Décision

Air adopte un IPC propre nommé AirCom pour la communication entre ses propres services natifs. D-Bus reste utilisé exclusivement pour interopérer avec l’écosystème Linux existant, jamais comme transport interne d’Air.

Cette décision se décompose en quatre points fermes :

  1. AirCom est le transport interne des services Air entre eux. Tout appel d’un composant Air vers un autre composant Air (compositeur, services système, applications natives .airapp, etc.) passe par AirCom. Aucun service Air natif n’expose son API principale via D-Bus.

  2. systemd est consommé via sd-bus en mode peer-to-peer. Air parle à systemd, systemd-logind, systemd-resolved, systemd-journald, systemd --user via sd-bus configuré pour parler directement aux sockets privés des services systemd, sans passer par le broker dbus-daemon. Le wire format D-Bus est utilisé sur ces sockets, mais sans dépendance au broker. Cohérent avec ADR-005.

  3. Un pont D-Bus optionnel (air-dbus-bridge) est disponible pour interopérer avec le reste de l’écosystème. NetworkManager, BlueZ, UPower, ModemManager et les autres services D-Bus traditionnels sont accessibles via ce pont, chargé à la demande dans les profils où il est utile (typiquement air-desktop). Il n’est pas requis pour air-base.

  4. xdg-desktop-portal-air est une exception assumée. Ce composant parle D-Bus de bout en bout parce que le standard xdg-desktop-portal est D-Bus-based par construction. Cette exception est documentée comme telle, ne s’étend à aucun autre composant Air, et préserve la compatibilité avec les applications tierces (Flatpak, GTK, Qt) qui consomment les portals.

Pourquoi pas D-Bus comme transport principal

Les arguments qui suivent sont des propriétés architecturales de D-Bus, pas des opinions. Ils sont vérifiables dans la spécification D-Bus elle-même (D-Bus Specification) et dans la documentation des projets qui ont tenté de faire évoluer D-Bus (kdbus, bus1, dbus-broker). Chaque propriété est ensuite mise en regard d’une exigence Air précise.

Le coût architectural d’un broker centralisé

D-Bus, dans sa forme déployée standard (dbus-daemon ou dbus-broker), fait transiter tout message à travers un processus broker. Chaque message émis par un client traverse donc deux frontières kernel/userspace : l’émetteur écrit dans le socket vers le broker, le broker lit, route, écrit dans le socket vers le destinataire, le destinataire lit. Sur un message de N octets, c’est deux copies kernel.

Pour les messages de contrôle de petite taille, ce coût est négligeable. Pour les charges de données plus volumineuses (transfert d’images, audio, vidéo, structures de données binaires partagées), il devient significatif. Le projet dbus-broker a publié des benchmarks montrant des améliorations d’un ordre de grandeur par rapport à dbus-daemon (dbus-broker repository, README et discussions associées) sans pour autant remettre en cause le modèle conceptuel à double copie.

Cohérence avec Air : la Charte principe 4 (longévité du matériel) et l’ADR-014 (catalogue matériel incluant Raspberry Pi 4 comme machine de référence) imposent qu’Air fonctionne avec fluidité sur du matériel modeste. Le Principe d’ingénierie 5 (optimiser après mesure) ne dispense pas de choisir des architectures qui n’imposent pas un surcoût intrinsèque. La double copie systématique d’un broker centralisé est un surcoût intrinsèque que la performance applicative ne peut pas compenser.

Le typage et le versioning des interfaces

D-Bus définit un système de types signature-based (s, u, a{sv}, etc.) sans schéma versionné. Une interface D-Bus n’a pas de mécanisme natif pour exprimer une évolution compatible ou incompatible. La compatibilité ascendante repose sur des conventions (introspection XML), pas sur une discipline outillée. Quand une signature change, la rupture est silencieuse côté wire format ; elle peut n’apparaître qu’au moment où un client tombe sur un type inattendu.

À titre de comparaison, les IPC schema-first contemporains (Cap’n Proto, Protobuf, FIDL) imposent un fichier de schéma compilé qui définit l’ABI/API et permet de vérifier en build et en CI que les évolutions respectent les règles de compatibilité (champs réservés, ordres canoniques, etc.).

Cohérence avec Air : le Principe d’ingénierie 8 (stabilité contractuelle) et l’ADR-012 (stratégie de versionnement, zones air-stable / air-internal / air-experimental, garantie 10 ans) imposent que tout contrat public soit testable en CI pour sa stabilité ABI. Construire cette infrastructure de tests sur D-Bus est possible mais demanderait de reconstruire une couche schema-first par-dessus. À ce stade, autant adopter un IPC qui est schema-first par construction.

Le FD passing

D-Bus permet de passer des descripteurs de fichiers entre processus via le type h (UNIX_FD). Cette fonctionnalité a été ajoutée tardivement (D-Bus 1.3, 2010), n’est pas supportée sur tous les transports, et reste limitée par les permissions et le routage du broker.

Le passage de FDs est un mécanisme fondamental pour Air : il permet le partage de mémoire zero-copy (via memfd_create), le transfert efficace de buffers GPU (via DMA-BUF), et l’établissement de canaux directs entre processus sans passer par le broker à chaque message. Air a besoin que le FD passing soit un mécanisme de première classe, intégré au wire format dès la conception.

Cohérence avec Air : ADR-002 (modèle d’objet C-ABI, services Air entre eux), ADR-003 (compositeur Wayland natif, transferts GPU), et les besoins de performance sur matériel modeste demandent un FD passing rapide et systématique, pas réservé à des cas particuliers.

Zero-copy et back-pressure

D-Bus n’a pas de mécanisme natif de zero-copy pour les charges volumineuses. Tout payload est sérialisé/désérialisé dans le format de wire D-Bus, et copié à travers le broker. Pour transférer un Mo d’image, c’est un Mo sérialisé, copié vers le broker, copié vers le destinataire, désérialisé.

D-Bus n’a pas non plus de mécanisme natif de back-pressure : si un client lent ne consomme pas ses messages, ils s’accumulent dans le broker jusqu’à atteindre des limites configurables, après quoi la connexion est tuée. Il n’y a pas de signal de saturation propre transmis à l’émetteur.

Cohérence avec Air : ADR-009 (framework de vues déclaratif) et l’architecture en couches d’Air supposent un flux de données entre services capable de traiter du contenu volumineux (images vectorielles riches, captures vectorielles selon ADR-018, audio/vidéo selon le futur ADR « framework networking couche 2 »). Le zero-copy via memfd_create partagé en mémoire est la solution standard pour ces cas, et elle n’est pas accessible naturellement via D-Bus. Le back-pressure explicite est nécessaire pour le streaming, et son absence native dans D-Bus serait à reconstruire par-dessus.

Le modèle de sécurité par policy XML

D-Bus contrôle l’accès aux services via des fichiers de policy XML (/etc/dbus-1/system.d/*.conf notamment) qui définissent qui peut s’adresser à qui. Ces policies sont statiques au chargement du broker, gérées par la distribution, et combinées en pratique avec polkit pour les autorisations dynamiques.

Ce modèle a deux conséquences notables :

  • L’autorisation est ambient. Un processus qui peut s’adresser au service D-Bus org.freedesktop.NetworkManager peut le faire par défaut tant que la policy le permet. Il n’y a pas de capability unforgeable transmise au démarrage de l’application qui matérialise cette autorisation.
  • L’évolution des policies se fait hors processus applicatif. Ajouter une autorisation pour une application passe par un fichier de configuration administratif, pas par un manifeste applicatif signé.

Cohérence avec Air : ADR-010 (.airapp / .airservice avec entitlements déclaratifs signés, sandbox capability-based) impose un modèle où chaque application reçoit au démarrage un ensemble explicite de capabilities, transportées de manière non falsifiable, vérifiables à la signature du bundle, révoquables. Ce modèle est radicalement différent de l’autorisation par policy XML. Le construire au-dessus de D-Bus reviendrait à ignorer son mécanisme de sécurité natif pour en bâtir un nouveau — ce qui défait l’argument d’usage de D-Bus.

Alternatives évaluées

kdbus (2013-2017)

kdbus était une réimplémentation de D-Bus dans le kernel Linux, proposée par Greg Kroah-Hartman et l’équipe systemd entre 2013 et 2015. L’objectif était de résoudre les problèmes de performance et de sécurité du broker userspace en faisant transiter les messages via un mécanisme kernel dédié. Après plusieurs cycles de revue, kdbus a été refusé par la communauté kernel pour des raisons d’architecture et de complexité (discussions LWN sur kdbus, 2014-2015 ; cf. notamment lwn.net/Articles/580194, lwn.net/Articles/641275). Le code n’a jamais été mergé dans le mainline.

Conclusion : la voie d’évolution in-kernel de D-Bus a été explorée et n’a pas abouti. Air n’a pas à parier sur sa résurrection.

bus1 (2016-2018)

bus1 était le successeur conceptuel de kdbus, une couche IPC capability-based en kernel, plus générique que kdbus. Présentée en 2017 (présentation linux.conf.au 2017, lwn.net/Articles/707925). Le projet n’a pas non plus été mergé dans le mainline et son développement public s’est essoufflé.

Conclusion : la voie d’un IPC capability-based standardisé en kernel pour Linux n’existe pas aujourd’hui.

dbus-broker

dbus-broker est une réimplémentation moderne du broker D-Bus userspace, par Tom Gundersen et David Herrmann (github.com/bus1/dbus-broker). Il améliore significativement les performances par rapport à dbus-daemon et corrige certains défauts d’implémentation. Il devient progressivement le broker par défaut sur plusieurs distributions.

dbus-broker adresse les problèmes d’implémentation du broker, pas les contraintes architecturales du modèle D-Bus (broker centralisé, typage par signatures, modèle de sécurité par policy, etc.). Air reconnaît dbus-broker comme une bonne implémentation de D-Bus mais ne le retient pas comme transport principal.

Conclusion : un meilleur broker reste un broker. Les exigences d’Air sont sur le modèle conceptuel, pas sur la performance du broker actuel.

Évolution incrémentale de D-Bus

Étendre D-Bus pour qu’il devienne schema-first, capability-based, zero-copy, etc. est techniquement possible mais reviendrait à le réinventer en cassant la compatibilité avec son écosystème. La valeur de D-Bus tient en grande partie à sa stabilité et à son ubiquité ; toute évolution qui le rendrait incompatible avec les services existants détruirait cette valeur sans bénéfice net.

Conclusion : l’option « D-Bus 2.0 incompatible » serait moins utile à l’écosystème que le maintien de D-Bus dans son rôle actuel et la coexistence avec un IPC distinct pour les besoins qu’il ne couvre pas.

AirCom en synthèse

AirCom est l’IPC interne d’Air. Sa spécification détaillée fera l’objet de documents et d’ADRs ultérieurs, mais ses caractéristiques structurantes, telles qu’elles découlent du présent ADR, sont les suivantes :

  • Transport : Unix sockets pour le control plane (messages courts, signalisation), memfd_create + mmap pour le data plane bulk (charges volumineuses zero-copy), io_uring pour les opérations asynchrones (cf. ADR-022).
  • Pas de broker central. Les services Air se découvrent via un registre léger (air-registry, couche 5) qui fournit les adresses de socket ; toute communication ultérieure est peer-to-peer entre client et service.
  • Modèle capability-based. Une application reçoit au démarrage les capabilities AirCom que son manifeste signé (.airapp, cf. ADR-010) déclare. Une capability est un handle non falsifiable transporté via FD passing. Aucune autorité ambient ; aucune découverte de services non autorisés.
  • Encodage schema-first. Les interfaces AirCom sont définies dans des fichiers de schéma compilés, avec versioning explicite et règles de compatibilité testées en CI (cf. Principe d’ingénierie 8 et ADR-012).
  • Inspirations. AirCom s’inspire ouvertement de XPC sur macOS (modèle capability-based, NSXPCConnection), de Cap’n Proto (sérialisation schema-first sans copies, support natif des FDs), de FIDL sur Fuchsia (IPC capability-based avec channels typés), et dans une moindre mesure de Mojo sur Chromium et de Binder sur Android. Cap’n Proto est candidat comme base technique pour l’encodage du wire format.
  • Pas un service système universel. AirCom ne vise pas à remplacer D-Bus dans l’écosystème Linux. Il est l’IPC d’Air pour Air. Les services D-Bus existants restent accessibles via les ponts décrits ci-après.

Le pont D-Bus dans Air

Le périmètre exact d’usage de D-Bus par Air est triple :

sd-bus peer-to-peer pour systemd

sd-bus, fourni par libsystemd, peut être configuré pour parler directement à un service systemd sans passer par le broker dbus-daemon. Le wire format reste D-Bus, le transport reste un socket Unix, mais le broker n’est pas dans le chemin. Cette technique est utilisée par Air pour parler à systemd, systemd-logind, systemd-resolved, systemd-journald, systemd --user. Aucune dépendance fonctionnelle à dbus-daemon ou dbus-broker. Cohérent avec ADR-005.

air-dbus-bridge (couche 2, optionnel)

Un composant chargeable à la demande, présent dans le profil air-desktop, qui expose les services D-Bus traditionnels (NetworkManager, BlueZ, UPower, ModemManager, accountsservice, etc.) sous forme de services AirCom consommables par les applications Air natives. La traduction AirCom ↔ D-Bus est gérée par air-dbus-bridge qui :

  • Consomme D-Bus côté éco-système (broker classique).
  • Expose une API AirCom côté Air, avec schémas typés et capabilities.

Une application Air native n’invoque jamais D-Bus directement. Elle consomme air.system.network, air.system.bluetooth, etc., via AirCom ; air-dbus-bridge fait la traduction. Si l’utilisateur n’utilise jamais ces services, le pont n’est pas chargé.

Pour air-base (profil console), le pont n’est pas requis. Les services d’écosystème pertinents pour air-base (typiquement systemd) sont accessibles via sd-bus peer-to-peer.

xdg-desktop-portal-air (exception assumée)

xdg-desktop-portal-air est l’implémentation Air du standard xdg-desktop-portal, qui définit comment les applications sandboxées (Flatpak, Snap, et les .airapp cibles freedesktop) demandent l’accès à des ressources protégées (fichiers, capture d’écran, impression, etc.). Le standard est D-Bus-based par construction. xdg-desktop-portal-air parle donc D-Bus à ses clients et à ses backends, et expose en interne une bridge vers AirCom pour la suite du flux.

Cette exception est explicitement documentée, ne s’étend à aucun autre composant Air, et permet à Air de respecter pleinement le standard freedesktop sans renoncer à AirCom en interne.

Articulation avec les autres ADRs

  • ADR-002 (modèle d’objet hybride asymétrique C-ABI) : AirCom transporte des invocations de méthodes sur des AirObject. Le modèle d’objet et l’IPC sont conçus conjointement, ce qui n’est pas le cas avec D-Bus.
  • ADR-005 (intégration systemd dure, D-Bus optionnel) : ADR-005 acte la dépendance dure à systemd et l’optionalité de dbus-daemon. ADR-001 précise la décision IPC qui en découle pour les services Air natifs.
  • ADR-010 (.airapp / .airservice, entitlements déclaratifs signés) : le modèle capability-based de AirCom est la conséquence directe du modèle d’entitlements d’ADR-010. Les deux ADRs sont complémentaires : ADR-010 acte les entitlements, ADR-001 acte le transport qui matérialise les capabilities correspondantes.
  • ADR-012 (versionnement, stabilité ABI 10 ans) : AirCom schema-first rend la stabilité ABI testable en CI, condition nécessaire à l’engagement de 10 ans d’ADR-012.
  • ADR-013 (distribution Modèle C → B) : pendant la phase d’incubation, les apps natives .airapp coexistent avec des apps tierces (Flatpak, GTK, Qt) qui consomment D-Bus. Le pont assure la cohabitation.
  • ADR-022 (architecture du module io_uring) : AirCom s’appuie sur io_uring pour ses opérations asynchrones de soumission/complétion, ce qui n’est pas naturel avec un broker D-Bus.

Questions courantes anticipées

« Pourquoi pas étendre D-Bus pour qu’il fasse ce qu’Air veut ? » — La voie a été explorée (kdbus, bus1) sans aboutir. Étendre D-Bus de manière incompatible briserait son écosystème. Étendre D-Bus de manière compatible reconstruirait par-dessus ce que AirCom construit en partant des bonnes primitives.

« Est-ce qu’Air refuse de parler à NetworkManager, BlueZ, etc. ? » — Non. Ces services restent accessibles via air-dbus-bridge qui les expose en AirCom aux applications Air. Air respecte et utilise l’écosystème D-Bus pour interopérer.

« Est-ce que c’est du Not-Invented-Here ? » — AirCom s’inspire ouvertement de XPC, Cap’n Proto, FIDL, Mojo, Binder. Le but n’est pas l’originalité, c’est la cohérence interne du SDK Air et la prise en charge native de besoins (capability-based, zero-copy, schema-first) que D-Bus ne couvre pas.

« Pourquoi pas s’aligner sur ce que fait Flatpak / Snap / etc. ? » — Flatpak et Snap s’appuient sur D-Bus parce qu’ils ciblent l’interopérabilité avec l’écosystème existant. Air a le même besoin pour les apps tierces (et c’est pour cela qu’il maintient air-dbus-bridge et xdg-desktop-portal-air), mais pour ses applications natives .airapp Air vise un modèle plus rigoureux que ce que D-Bus permet.

« AirCom va-t-il un jour devenir un standard freedesktop ? » — Ce n’est pas un objectif d’Air. AirCom est l’IPC interne d’Air. Si des projets externes y trouvent un intérêt, ils sont libres de l’adopter ou de s’en inspirer, mais Air ne cherche pas à pousser AirCom comme remplaçant de D-Bus dans l’écosystème.

« Le pont D-Bus n’est-il pas un single point of failure ? » — Le pont est optionnel et concerne uniquement l’interop avec les services tiers. Sa défaillance désactive l’accès à ces services tiers, mais les services Air natifs restent fonctionnels via AirCom. Pour systemd, le canal sd-bus peer-to-peer ne dépend pas du pont. Pour air-base, le pont n’est pas chargé du tout.

Conséquences

Bénéfices

  • Cohérence interne du SDK Air. Un seul modèle de communication entre services Air, conçu conjointement avec le modèle d’objet (ADR-002) et le modèle d’entitlements (ADR-010).
  • Stabilité ABI testable. Schema-first → tests automatisés de compatibilité en CI, cohérent avec ADR-012 et le Principe d’ingénierie 8.
  • Performance prévisible. Pas de double copie par broker, FD passing de première classe, zero-copy via memfd_create pour les charges volumineuses. Cohérent avec ADR-014 et la Charte principe 4.
  • Modèle de sécurité unifié. Capabilities AirCom = capabilities applicatives = entitlements signés. Cohérent avec ADR-010.

Coûts

  • Double stack d’IPC. Air maintient AirCom pour son cœur et un pont D-Bus pour l’interop. C’est plus à construire et à maintenir qu’une stack unique. Ce coût est jugé acceptable parce qu’aucune stack unique ne couvre les deux besoins (besoins internes Air + interop écosystème).
  • Outillage à construire. AirCom demande son propre runtime, son compilateur de schémas, ses outils de tests, son inspecteur de tronc. C’est du travail concentré en phase 2 (cf. ADR-011), avec un livrable lisible (air-notifyd comme premier service AirCom) en fin de phase 2.
  • Pédagogie nécessaire. Le choix peut surprendre les contributeurs venant de l’écosystème D-Bus traditionnel. Le présent ADR vise précisément à rendre la décision compréhensible et défendable, sans posture évangéliste ni rejet de D-Bus.

Risques et mitigations

  • Risque : AirCom reste obscur et adoption faible par les développeurs tiers. Mitigation : qualité d’outillage (introspection, debugger, bindings polyglottes via le modèle d’objet C-ABI d’ADR-002), documentation claire, ergonomie soignée. La valeur principale est d’abord pour les apps natives .airapp, le reste suit.
  • Risque : l’écosystème D-Bus évolue (par exemple un futur dbus2 schema-first capability-based) et rend AirCom redondant. Mitigation : la décision est révisable comme tout ADR (mécanisme RFC après ouverture publique, cf. ADR-015). Une telle évolution serait sérieusement évaluée.
  • Risque : interop incomplète avec un service D-Bus tiers important. Mitigation : air-dbus-bridge est conçu pour rendre n’importe quel service D-Bus consommable depuis Air ; les cas pathologiques (services D-Bus reposant sur des particularités du broker) sont traités au cas par cas.

Statut futur

ADR fondateur immuable dans son principe (AirCom comme transport interne, D-Bus pour interop). Les détails de AirCom (wire format exact, choix Cap’n Proto vs alternative, format du registre, etc.) feront l’objet d’ADRs et de specs ultérieurs au moment de l’implémentation en phase 2 (cf. ADR-011).

ADRs ultérieurs identifiés :

  • Spécification détaillée du wire format AirCom (probablement basé sur Cap’n Proto, à confirmer en phase 2).
  • Protocole privé AirCom entre air-wm et les apps natives (rich content, animations, capture vectorielle scene-graph).
  • Politique de versioning des schémas AirCom (compatibilité ascendante, champs réservés, etc.) et outillage air-abi-check correspondant.

Licence du document : MPL 2.0 Statut : Document fondateur immuable.