DCOP"},"genre":{"wt":"{{unbulleted list|[[Inter-process communication|IPC]] [[Daemon (computing)|daemon]] | [[Linux on the desktop]]}}"},"license":{"wt":"[[GNU General Public Li...
Hispanopedia WikiContenido en espanolLectura gratuita
El proyecto freedesktop.org también desarrolló una biblioteca de software libre y de código abierto llamada libdbus, como implementación de referencia de la especificación. Esta biblioteca no es D-Bus en sí misma, ya que también existen otras implementaciones de la especificación D-Bus, como GDBus (GNOME), [ 8 ] QtDBus ( Qt /KDE), [ 9 ] dbus-java [ 10 ] y sd-bus (parte de systemd ). [ 11 ]
Descripción general
D-Bus es un mecanismo de comunicación entre procesos (IPC) diseñado inicialmente para reemplazar los sistemas de comunicación de componentes de software CORBA y DCOP, utilizados por los entornos de escritorio GNOME y KDE Linux , respectivamente. [ 12 ] [ 13 ] Los componentes de estos entornos de escritorio normalmente se distribuyen en muchos procesos, cada uno de los cuales proporciona solo uno o unos pocos servicios . Estos servicios pueden ser utilizados por aplicaciones cliente habituales o por otros componentes del entorno de escritorio para realizar sus tareas.
Procesos sin D-Bus
Los mismos procesos con D-Bus
Los grandes grupos de procesos que cooperan entre sí requieren una densa red de canales de comunicación individuales (mediante métodos IPC uno a uno). D-Bus simplifica los requisitos de IPC con un único canal compartido.
D-Bus proporciona una abstracción de bus de software que reúne todas las comunicaciones entre un grupo de procesos a través de un único canal virtual compartido. [ 5 ] Los procesos conectados a un bus desconocen su implementación interna, pero la especificación D-Bus garantiza que todos los procesos conectados al bus pueden comunicarse entre sí a través de él. D-Bus conlleva una pérdida de rendimiento de al menos 2,5 veces en comparación con la comunicación entre procesos (IPC) uno a uno. [ 14 ]
Los entornos de escritorio Linux aprovechan las funcionalidades de D-Bus mediante la instanciación de múltiples buses, en particular: [ 15 ] [ 5 ] [ 16 ]
un único bus del sistema , disponible para todos los usuarios y procesos del sistema, que proporciona acceso a los servicios del sistema (es decir, servicios proporcionados por el sistema operativo y también por cualquier demonio del sistema ); y
Un bus de sesión para cada sesión de inicio de sesión de usuario, que proporciona servicios de escritorio a las aplicaciones de usuario en la misma sesión de escritorio y permite la integración de la sesión de escritorio en su conjunto.
Un proceso puede conectarse a cualquier número de buses, siempre que se le haya concedido acceso a ellos. En la práctica, esto significa que cualquier proceso de usuario puede conectarse al bus del sistema y a su bus de sesión actual, pero no a los buses de sesión de otro usuario, ni siquiera a un bus de sesión diferente perteneciente al mismo usuario. Esta última restricción podría cambiar en el futuro si todas las sesiones de un usuario se combinan en un único bus de usuario. [ 17 ]
D-Bus proporciona funcionalidades adicionales o simplifica las existentes para las aplicaciones, incluyendo el intercambio de información, la modularidad y la separación de privilegios . Por ejemplo, la información sobre una llamada de voz entrante recibida a través de Bluetooth o Skype puede propagarse e interpretarse por cualquier reproductor de música en ejecución, que puede reaccionar silenciando el volumen o pausando la reproducción hasta que finalice la llamada. [ 18 ]
D-Bus también puede utilizarse como marco para integrar diferentes componentes de una aplicación de usuario. Por ejemplo, una suite ofimática puede comunicarse a través del bus de sesión para compartir datos entre un procesador de textos y una hoja de cálculo .
Especificación D-Bus
Modelo de autobús
Cada conexión a un bus se identifica en el contexto de D-Bus mediante lo que se denomina un nombre de bus . [ 4 ] Existen dos tipos de nombres de bus: únicos y conocidos . Un nombre de bus conocido consta de dos o más cadenas separadas por puntos de letras, dígitos, guiones y guiones bajos: un nombre de dominio inverso . Un ejemplo de un nombre de bus válido es org.freedesktop.NetworkManager. [ 5 ]
Cuando un proceso establece una conexión a un bus, el bus asigna a la conexión un nombre de bus especial llamado nombre de conexión único . [ 16 ] [ 5 ] Los nombres de bus de este tipo son inmutables; se garantiza que no cambiarán mientras exista la conexión y, lo que es más importante, no se pueden reutilizar durante la vida útil del bus. [ 4 ] [ 16 ] [ 5 ] Esto significa que ninguna otra conexión a ese bus tendrá asignado dicho nombre de conexión único, incluso si el mismo proceso cierra la conexión al bus y crea una nueva. Los nombres de conexión únicos son fácilmente reconocibles porque comienzan con el carácter de dos puntos, que de otro modo estaría prohibido. [ 16 ] [ 5 ] Un ejemplo de un nombre de conexión único es :1.1553(los caracteres después de los dos puntos no tienen un significado particular [ 16 ] ).
Un proceso puede solicitar nombres de bus adicionales para su conexión, [ 16 ] siempre que ningún nombre solicitado esté siendo utilizado ya por otra conexión al bus. En la terminología de D-Bus, cuando se asigna un nombre de bus a una conexión, se dice que la conexión es propietaria del nombre del bus. [ 4 ] [ 16 ] En ese sentido, un nombre de bus no puede ser propiedad de dos conexiones al mismo tiempo, pero, a diferencia de los nombres de conexión únicos, estos nombres pueden reutilizarse si están disponibles: un proceso puede reclamar un nombre de bus liberado —intencionadamente o no— por otro proceso. [ 4 ] [ 5 ]
La idea detrás de estos nombres de bus adicionales, comúnmente llamados nombres conocidos , es proporcionar una forma de referirse a un servicio utilizando un nombre de bus preestablecido. [ 16 ] [ 5 ] Por ejemplo, el servicio que informa la hora y fecha actuales en el bus del sistema se encuentra en el proceso cuya conexión posee el nombre de bus org.freedesktop.timedate1 , independientemente de qué proceso sea.
Los nombres de bus pueden utilizarse como una forma sencilla de implementar aplicaciones de instancia única (las instancias secundarias detectan que el nombre de bus ya está ocupado). [ 16 ] También pueden utilizarse para rastrear el ciclo de vida de un proceso de servicio, ya que el bus envía una notificación cuando se libera un nombre de bus debido a la finalización de un proceso. [ 16 ]
Modelo de objeto
Debido a su concepción original como reemplazo de varios sistemas de comunicación orientados a componentes, D-Bus comparte con sus predecesores un modelo de objetos para expresar la semántica de las comunicaciones entre clientes y servicios. Los términos utilizados en el modelo de objetos de D-Bus imitan los empleados por algunos lenguajes de programación orientados a objetos . Esto no significa que D-Bus esté limitado a lenguajes de POO; de hecho, la implementación más utilizada ( libdbus ) está escrita en C , un lenguaje de programación procedimental .
Explorar los nombres de bus, objetos, interfaces, métodos y señales existentes en un bus D-Bus usando D-Feet
En D-Bus, un proceso ofrece sus servicios exponiendo objetos . Estos objetos tienen métodos que se pueden invocar y señales que el objeto puede emitir. [ 16 ] Los métodos y las señales se denominan colectivamente miembros del objeto. [ 4 ] Cualquier cliente conectado al bus puede interactuar con un objeto utilizando sus métodos, realizando solicitudes o ordenándole que realice acciones. [ 16 ] Por ejemplo, un cliente puede consultar un objeto que representa un servicio de tiempo utilizando un método que devuelve la fecha y hora actuales. Un cliente también puede escuchar las señales que emite un objeto cuando su estado cambia debido a ciertos eventos, generalmente relacionados con el servicio subyacente. Un ejemplo sería cuando un servicio que administra dispositivos de hardware, como controladores USB o de red, señala un evento de "nuevo dispositivo de hardware agregado". Los clientes deben indicar al bus que están interesados en recibir ciertas señales de un objeto en particular, ya que un bus D-Bus solo pasa señales a aquellos procesos que tienen un interés registrado en ellas. [ 5 ]
Un proceso conectado a un bus D-Bus puede solicitarle que exporte tantos objetos D-Bus como desee. Cada objeto se identifica mediante una ruta de objeto , una cadena de números, letras y guiones bajos separados y precedidos por el carácter de barra diagonal, llamada así por su semejanza con las rutas del sistema de archivos Unix . [ 4 ] [ 16 ] La ruta de objeto es seleccionada por el proceso solicitante y debe ser única en el contexto de esa conexión de bus. Un ejemplo de una ruta de objeto válida es /org/kde/kspread/sheets/3/cells/4/5. [ 16 ] Sin embargo, no es obligatorio —pero tampoco desaconsejable— formar jerarquías dentro de las rutas de objeto. [ 5 ] La convención de nomenclatura particular para los objetos de un servicio depende completamente de los desarrolladores de dicho servicio, pero muchos desarrolladores optan por usar el nombre de dominio reservado del proyecto como prefijo (por ejemplo , /org/kde ). [ 16 ]
Cada objeto está intrínsecamente asociado a la conexión de bus específica desde la que se exportó y, desde el punto de vista de D-Bus, solo existe en el contexto de dicha conexión. Por lo tanto, para poder utilizar un servicio determinado, un cliente debe indicar no solo la ruta del objeto que proporciona el servicio deseado, sino también el nombre del bus bajo el cual el proceso de servicio está conectado al bus. [ 4 ] Esto, a su vez, permite que varios procesos conectados al bus puedan exportar diferentes objetos con rutas de objeto idénticas de forma inequívoca.
Una interfaz especifica miembros (métodos y señales) que se pueden usar con un objeto. [ 16 ] Es un conjunto de declaraciones de métodos (incluidos sus parámetros de paso y retorno) y señales (incluidos sus parámetros) identificados por un nombre separado por puntos que se asemeja a la notación de interfaces del lenguaje Java . [ 16 ] [ 5 ] Un ejemplo de un nombre de interfaz válido es org.freedesktop.Introspectable. [ 5 ] A pesar de su similitud, no se deben confundir los nombres de las interfaces con los nombres de los buses. Un objeto D-Bus puede implementar varias interfaces, pero al menos debe implementar una, proporcionando soporte para cada método y señal definidos por ella. La combinación de todas las interfaces implementadas por un objeto se llama tipo de objeto . [ 4 ] [ 16 ]
Al utilizar un objeto, es recomendable que el proceso cliente proporcione el nombre de la interfaz del miembro además del nombre del miembro, pero esto solo es obligatorio cuando existe una ambigüedad causada por nombres de miembros duplicados disponibles en diferentes interfaces implementadas por el objeto [ 4 ] [ 16 ]; de lo contrario, el miembro seleccionado no está definido o es erróneo. Por otro lado, una señal emitida siempre debe indicar a qué interfaz pertenece.
La especificación D-Bus también define varias interfaces estándar que los objetos pueden querer implementar además de sus propias interfaces. [ 15 ] Aunque técnicamente opcional, la mayoría de los desarrolladores de servicios D-Bus optan por admitirlas en sus objetos exportados, ya que ofrecen características adicionales importantes a los clientes D-Bus, como la introspección . [ 5 ] Estas interfaces estándar son: [ 15 ] [ 5 ]
org.freedesktop.DBus.Peer : proporciona una forma de comprobar si una conexión D-Bus está activa. [ 5 ]
org.freedesktop.DBus.Introspectable : proporciona un mecanismo de introspección mediante el cual un proceso cliente puede, en tiempo de ejecución, obtener una descripción (en formato XML ) de las interfaces, métodos y señales que implementa el objeto. [ 16 ] [ 15 ]
org.freedesktop.DBus.Properties : permite que un objeto D-Bus exponga las propiedades o atributos del objeto nativo subyacente, o los simule si no existen. [ 15 ]
org.freedesktop.DBus.ObjectManager : cuando un servicio D-Bus organiza sus objetos jerárquicamente, esta interfaz proporciona una forma de consultar un objeto sobre todos los subobjetos que se encuentran bajo su ruta, así como sus interfaces y propiedades, utilizando una única llamada a un método. [ 15 ]
La especificación D-Bus define una serie de operaciones administrativas de bus (denominadas "servicios de bus") que se realizan utilizando el objeto /org/freedesktop/DBus que reside en el nombre de bus org.freedesktop.DBus . [ 15 ] Cada bus reserva este nombre de bus especial para sí mismo y gestiona cualquier solicitud realizada específicamente a esta combinación de nombre de bus y ruta de objeto. Las operaciones administrativas proporcionadas por el bus son las definidas por la interfaz del objeto org.freedesktop.DBus . Estas operaciones se utilizan, por ejemplo, para proporcionar información sobre el estado del bus, [ 4 ] o para gestionar la solicitud y liberación de nombres de bus conocidos adicionales . [ 15 ] [ 5 ]
Modelo de comunicaciones
D-Bus fue concebido como un sistema de comunicación entre procesos genérico y de alto nivel. Para lograr estos objetivos, las comunicaciones D-Bus se basan en el intercambio de mensajes entre procesos en lugar de "bytes sin procesar". [ 4 ] [ 16 ] Los mensajes D-Bus son elementos discretos de alto nivel que un proceso puede enviar a través del bus a otro proceso conectado. Los mensajes tienen una estructura bien definida (incluso los tipos de datos que transportan en su carga útil están definidos), lo que permite al bus validarlos y rechazar cualquier mensaje mal formado. En este sentido, D-Bus está más cerca de un mecanismo RPC que de un mecanismo IPC clásico, con su propio sistema de definición de tipos y su propio serializado . [ 4 ]
Ejemplo de intercambio de mensajes de solicitud-respuesta uno a uno para invocar un método a través de D-Bus. Aquí, el proceso cliente invoca el método SetFoo() del objeto /org/example/object1 del proceso de servicio llamado org.example.foo (o ) en el bus.:1.14
El bus admite dos modos de intercambio de mensajes entre un cliente y un proceso de servicio [ 4 ] :
Solicitud-respuesta uno a uno : Esta es la forma en que un cliente invoca el método de un objeto. El cliente envía un mensaje al proceso de servicio que exporta el objeto, y el servicio, a su vez, responde con un mensaje al proceso del cliente. [ 16 ] El mensaje enviado por el cliente debe contener la ruta del objeto, el nombre del método invocado (y opcionalmente el nombre de su interfaz) y los valores de los parámetros de entrada (si los hay) según lo definido por la interfaz seleccionada del objeto. El mensaje de respuesta contiene el resultado de la solicitud, incluidos los valores de los parámetros de salida devueltos por la invocación del método del objeto, o información de excepción si hubo un error. [ 4 ] [ 16 ]
Publicar/suscribir : Este es el modo en que un objeto anuncia la ocurrencia de una señal a las partes interesadas. El proceso de servicio del objeto difunde un mensaje que el bus solo transmite a los clientes conectados suscritos a la señal del objeto. [ 16 ] El mensaje contiene la ruta del objeto, el nombre de la señal, la interfaz a la que pertenece la señal y también los valores de los parámetros de la señal (si los hay). La comunicación es unidireccional: no hay mensajes de respuesta al mensaje original por parte de ningún proceso cliente, ya que el remitente desconoce tanto la identidad como el número de destinatarios. [ 4 ] [ 16 ]
Cada mensaje D-Bus consta de una cabecera y un cuerpo. [ 16 ] La cabecera está formada por varios campos que identifican el tipo de mensaje, el remitente, así como la información necesaria para entregar el mensaje a su destinatario (nombre del bus de destino, ruta del objeto, nombre del método o señal, nombre de la interfaz, etc.). [ 16 ] [ 15 ] El cuerpo contiene la carga útil de datos que el proceso receptor interpreta, por ejemplo, los argumentos de entrada o salida. Todos los datos están codificados en un formato binario conocido llamado formato de cable que admite la serialización de varios tipos, como enteros y números de punto flotante, cadenas, tipos compuestos, etc., [ 15 ] también conocido como marshaling .
La especificación D-Bus define el protocolo de comunicación : cómo construir los mensajes D-Bus que se intercambiarán entre procesos dentro de una conexión D-Bus. Sin embargo, no define el método de transporte subyacente para la entrega de estos mensajes.
Interiores
La mayoría de las implementaciones de D-Bus existentes siguen la arquitectura de la implementación de referencia. Esta arquitectura consta de dos componentes principales: [ 4 ]
Una biblioteca de comunicaciones punto a punto que implementa el protocolo de comunicación D-Bus para intercambiar mensajes entre dos procesos. En la implementación de referencia, esta biblioteca se llama libdbus . En otras implementaciones, libdbus puede estar integrada en otra biblioteca de nivel superior, en una interfaz de lenguaje o ser reemplazada por completo por una implementación independiente diferente que cumpla la misma función. [ 19 ] Esta biblioteca solo admite comunicaciones uno a uno entre dos procesos. [ 16 ]
Un proceso dbus-daemon que actúa como un demonio de bus de mensajes D-Bus. Cada proceso conectado al bus mantiene una conexión D-Bus con él.un proceso demonio especial que actúa como bus y al que se conectan los demás procesos mediante cualquier biblioteca de comunicaciones punto a punto D-Bus. Este proceso también se conoce como demonio del bus de mensajes , [ 18 ] ya que es responsable de enrutar los mensajes de cualquier proceso conectado al bus a otro. En la implementación de referencia, esta función la desempeña dbus-daemon , que a su vez está construido sobre libdbus . Otra implementación del demonio del bus de mensajes es dbus-broker , que está construido sobre sd-bus .
Los procesos A y B tienen una conexión D-Bus uno a uno mediante libdbus a través de un socket de dominio Unix. Pueden usarla para intercambiar mensajes directamente. [ 20 ] En este escenario, no se requieren nombres de bus. [ 16 ]
Los procesos A y B se conectaron a un demonio dbus mediante libdbus a través de un socket de dominio Unix. Pueden intercambiar mensajes enviándolos al proceso del bus de mensajes, que a su vez los entregará al proceso correspondiente. En este caso, los nombres de los buses son obligatorios para identificar el proceso de destino.
La biblioteca libdbus (o su equivalente) utiliza internamente un mecanismo IPC nativo de bajo nivel para transportar los mensajes D-Bus necesarios entre los dos procesos en ambos extremos de la conexión D-Bus. La especificación D-Bus no impone qué mecanismos de transporte IPC particulares deben estar disponibles, ya que es la biblioteca de comunicaciones la que decide qué métodos de transporte admite. Por ejemplo, en sistemas operativos tipo Unix como Linux, libdbus suele utilizar sockets de dominio Unix como método de transporte subyacente, pero también admite sockets TCP . [ 4 ] [ 16 ]
Las bibliotecas de comunicaciones de ambos procesos deben acordar el método de transporte seleccionado y también el canal particular utilizado para su comunicación. Esta información se define mediante lo que D-Bus llama una dirección . [ 5 ] [ 16 ] Los sockets de dominio Unix son objetos del sistema de archivos y, por lo tanto, pueden identificarse mediante un nombre de archivo, por lo que una dirección válida sería unix:path=/tmp/.hiddensocket. [ 4 ] [ 15 ] Ambos procesos deben pasar la misma dirección a sus respectivas bibliotecas de comunicaciones para establecer la conexión D-Bus entre ellos. Una dirección también puede proporcionar datos adicionales a la biblioteca de comunicaciones en forma de key=valuepares separados por comas. [ 5 ] [ 15 ] De esta manera, por ejemplo, puede proporcionar información de autenticación a un tipo específico de conexión que lo admita.
Cuando se utiliza un demonio de bus de mensajes como dbus-daemon para implementar un bus D-Bus, todos los procesos que desean conectarse al bus deben conocer la dirección del bus , la dirección mediante la cual un proceso puede establecer una conexión D-Bus con el proceso central del bus de mensajes. [ 4 ] [ 16 ] En este escenario, el demonio del bus de mensajes selecciona la dirección del bus y los procesos restantes deben pasar ese valor a sus bibliotecas libdbus o equivalentes correspondientes. dbus-daemon define una dirección de bus diferente para cada instancia de bus que proporciona. Estas direcciones se definen en los archivos de configuración del demonio.
Dos procesos pueden usar una conexión D-Bus para intercambiar mensajes directamente entre ellos, [ 20 ] pero esta no es la forma en que D-Bus está diseñado normalmente para usarse. La forma habitual es usar siempre un demonio de bus de mensajes (es decir, dbus-daemon ) como punto central de comunicaciones al que cada proceso debe establecer su conexión D-Bus punto a punto. Cuando un proceso (cliente o servicio) envía un mensaje D-Bus, el proceso del bus de mensajes lo recibe en primera instancia y lo entrega al destinatario apropiado. El demonio del bus de mensajes puede considerarse como un concentrador o enrutador encargado de hacer llegar cada mensaje a su destino repitiéndolo a través de la conexión D-Bus al proceso receptor. [ 16 ] El proceso receptor se determina por el nombre del bus de destino en el campo de encabezado del mensaje, [ 15 ] o por la información de suscripción a las señales mantenida por el demonio del bus de mensajes en el caso de mensajes de propagación de señales. [ 5 ] El demonio del bus de mensajes también puede producir sus propios mensajes como respuesta a ciertas condiciones, como un mensaje de error a un proceso que envió un mensaje a un nombre de bus inexistente. [ 16 ]
dbus-daemon mejora el conjunto de características ya proporcionado por D-Bus con funcionalidad adicional. Por ejemplo, la activación de servicios permite el inicio automático de servicios cuando sea necesario, cuando la primera solicitud a cualquier nombre de bus de dicho servicio llega al demonio del bus de mensajes. [ 4 ] De esta manera, los procesos de servicio no necesitan iniciarse durante la etapa de inicialización del sistema o del usuario, ni necesitan consumir memoria u otros recursos cuando no se utilizan. Esta característica se implementó originalmente utilizando auxiliares setuid , [ 21 ] pero actualmente también puede ser proporcionada por el marco de activación de servicios de systemd . La activación de servicios es una característica importante que facilita la gestión del ciclo de vida de los procesos de los servicios (por ejemplo, cuándo debe iniciarse o detenerse un componente de escritorio). [ 16 ]
Historia y adopción
D-Bus fue creado en 2002 por Havoc Pennington, Alex Larsson ( Red Hat ) y Anders Carlsson. [ 7 ] La versión 1.0, considerada estable en cuanto a API , se lanzó en noviembre de 2006. [ 22 ] [ 23 ]
Fuertemente influenciado por el sistema DCOP utilizado por las versiones 2 y 3 de KDE , D-Bus ha reemplazado a DCOP en la versión KDE 4. [ 24 ] [ 23 ] [ 25 ] Una implementación de D-Bus admite la mayoría de los sistemas operativos POSIX , y existe un puerto para Windows . Es utilizado por Qt 4 y posteriormente por GNOME . En GNOME ha reemplazado gradualmente la mayor parte de las partes del mecanismo Bonobo anterior . También es utilizado por Xfce .
Uno de los primeros en adoptarlo fue la capa de abstracción de hardware (actualmente obsoleta) . HAL utilizaba D-Bus para exportar información sobre el hardware que se había añadido o eliminado del ordenador. [ 7 ]
El uso de D-Bus se está expandiendo progresivamente más allá del ámbito inicial de los entornos de escritorio para abarcar una cantidad cada vez mayor de servicios del sistema. Por ejemplo, el demonio de red NetworkManager , la pila Bluetooth BlueZ y el servidor de sonido PulseAudio utilizan D-Bus para proporcionar parte o la totalidad de sus servicios. systemd utiliza el protocolo de cable D-Bus para la comunicación entre systemctl y systemd, y también está promoviendo la adopción de demonios del sistema tradicionales como servicios D-Bus, como logind . [ 26 ] Otro usuario intensivo de D-Bus es Polkit , cuyo demonio de autoridad de políticas se implementa como un servicio conectado al bus del sistema. [ 27 ]
Implementaciones
libdbus
Aunque existen varias implementaciones de D-Bus, la más utilizada es la implementación de referencia libdbus , desarrollada por el mismo proyecto freedesktop.org que diseñó la especificación. Sin embargo, libdbus es una implementación de bajo nivel que nunca se concibió para ser utilizada directamente por desarrolladores de aplicaciones, sino como una guía de referencia para otras reimplementaciones de D-Bus (como las incluidas en las bibliotecas estándar de entornos de escritorio o en las bibliotecas de lenguajes de programación ). El propio proyecto freedesktop.org recomienda a los autores de aplicaciones que utilicen alguna de las bibliotecas o implementaciones de nivel superior. [ 28 ]
GDBus
GDBus [ 8 ] es una implementación de D-Bus basada en flujos GIO incluidos en GLib , con el objetivo de ser utilizada por GTK+ y GNOME . GDBus no es un envoltorio de libdbus, sino una reimplementación completa e independiente de la especificación y el protocolo D-Bus. [ 29 ] MATE Desktop [ 30 ] y Xfce (versión 4.14), que también se basan en GTK+ 3, también utilizan GDBus.
bus SD
En 2013, el proyecto systemd reescribió libdbus en un esfuerzo por simplificar el código, [ 31 ] pero también resultó en un aumento significativo del rendimiento general de D-Bus. En pruebas preliminares, BMW descubrió que la biblioteca D-Bus de systemd aumentó el rendimiento en un 360%. [ 32 ] Con la versión 221 de systemd , lanzada en 2015, la API sd-bus se declaró estable. [ 33 ]
kdbus
kdbus se implementa como un controlador de dispositivo de caracteres. [ 34 ] [ 35 ] Toda la comunicación entre procesos se realiza a través de nodos de dispositivo de caracteres especiales en /dev/kdbus(cf. devfs ).
kdbus fue un proyecto que pretendía reimplementar D-Bus como un mecanismo de comunicación entre procesos punto a punto mediado por el kernel . Además de las mejoras de rendimiento, kdbus tendría ventajas derivadas de otras características del kernel de Linux, como los espacios de nombres y la auditoría, [ 32 ] [ 36 ] la seguridad gracias a la mediación del kernel, el cierre de condiciones de carrera y la posibilidad de usar D-Bus durante el arranque y el apagado (según lo necesita systemd). [ 37 ] La inclusión de kdbus en el kernel de Linux resultó controvertida, [ 38 ] y se descartó en favor de BUS1 , como una comunicación entre procesos más genérica . [ 39 ]
↑ "Anuncio de dbus 1.16.2 (versión estable con corrección de errores)" . Consultado el 23 de marzo de 2025 .
↑ "Blog de Havoc, julio de 2007" . Archivado del original el 7 de septiembre de 2015. Consultado el 3 de octubre de 2012 .
↑ Ward, Brian (2004). «14: Un breve estudio del escritorio Linux». Cómo funciona Linux: Lo que todo superusuario debería saber (2.ª ed.). San Francisco: No Starch Press (publicado en 2014). pág. 305. ISBN9781593275679Recuperado el 7 de noviembre de 2016. Uno de los desarrollos más importantes surgidos del escritorio Linux es el Desktop Bus (D-Bus), un sistema de paso de mensajes. D-Bus es importante porque sirve como mecanismo de comunicación entre procesos que permite que las aplicaciones de escritorio se comuniquen entre sí [...].
↑ Vermeulen, Jeroen (14 de julio de 2013). "Introducción a D-Bus" . FreeDesktop.org . Consultado el 3 de octubre de 2015. D-Bus [...] está diseñado para usarse como una capa de middleware unificada debajo de los principales entornos de escritorio gratuitos.
1 2 3 Palmieri, John (enero de 2005). "Súbete a D-BUS" . Revista Red Hat. Archivado del original el 23 de octubre de 2015. Recuperado el 3 de noviembre de 2015 .
1 2 "gdbus" . Desarrollador de GNOME . Consultado el 4 de enero de 2015 .
↑ "Módulo QtDBus" . Proyecto Qt . Consultado el 1 de junio de 2015 .
↑ "Documentación de DBus-Java" . FreeDesktop.org . Consultado el 4 de enero de 2015 .
↑Poettering, Lennart (19 June 2015). "The new sd-bus API of systemd". Retrieved 21 October 2015.
↑Pennington, Havoc; Wheeler, David; Walters, Colin. "D-Bus Tutorial". Retrieved 21 October 2015. For the within-desktop-session use case, the GNOME and KDE desktops have significant previous experience with different IPC solutions such as CORBA and DCOP. D-Bus is built on that experience and carefully tailored to meet the needs of these desktop projects in particular.
↑Vermeulen, Jeroen (14 July 2013). "Introduction to D-Bus". FreeDesktop.org. Retrieved 3 October 2015. D-Bus was first built to replace the CORBA-like component model underlying the GNOME desktop environment. Similar to DCOP (which is used by KDE), D-Bus is set to become a standard component of the major free desktop environments for GNU/Linux and other platforms.
↑Poettering, Lennart (19 June 2015). "The new sd-bus API of systemd". Retrieved 21 October 2015. we are working on moving things to a true user bus, of which there is only one per user on a system, regardless how many times that user happens to log in
12Love, Robert (5 January 2005). "Get on the D-BUS". Linux Journal. Retrieved 14 October 2014.
↑"What is D-Bus?". FreeDesktop.org. Retrieved 29 October 2015. There are also some reimplementations of the D-Bus protocol for languages such as C#, Java, and Ruby. These do not use the libdbus reference implementation
12"What is D-Bus?". FreeDesktop.org. Retrieved 29 October 2015. is built on top of a general one-to-one message passing framework, which can be used by any two apps to communicate directly (without going through the message bus daemon)
↑"D-BUS System Activation". FreeDesktop.org. Retrieved 18 February 2016.
↑Palmieri, John (9 November 2006). "[announce] D-Bus 1.0.0 "Blue Bird" released". dbus (Mailing list).
12Molkentin, Daniel (12 November 2006). "D-Bus 1.0 "Blue Bird" Released". KDE News. Retrieved 3 November 2015.
↑"Control Your Linux Desktop with D-Bus | Linux Journal". www.linuxjournal.com. Retrieved 2026-05-30.
↑Seigo, Aaron. "Introduction To D-BUS". KDE TechBase. Retrieved 3 November 2015.
↑Poettering, Lennart (19 June 2015). "The new sd-bus API of systemd". Retrieved 21 October 2015. Since systemd's inception it has been the IPC system it exposes its interfaces on.
↑"Polkit reference manual". FreeDesktop.org. Retrieved 3 November 2015.
↑"What is D-Bus?". FreeDesktop.org. Retrieved 5 January 2015. The low-level implementation is not primarily designed for application authors to use. Rather, it is a basis for binding authors and a reference for reimplementations. If you are able to do so it is recommended that you use one of the higher level bindings or implementations.
↑"Migrating to GDBus". GNOME Developer. Retrieved 21 October 2015. dbus-glib uses the libdbus reference implementation, GDBus doesn't. Instead, it relies on GIO streams as transport layer, and has its own implementation for the D-Bus connection setup and authentication.
↑ "MATE: Hoja de ruta" . Archivado del original el 29 de julio de 2019. Consultado el 31 de enero de 2019 .
↑ Poettering, Lennart (20 de marzo de 2013). " [ AVISO ] Planes para libsystemd-bus + kdbus" . systemd-devel (Lista de correo).
1 2 Edge, Jake (30 de mayo de 2013). "ALS: Comunicación entre procesos de Linux y kdbus" . LWN.net . Recuperado el 21 de octubre de 2015 .
↑ Poettering, Lennart (19 de junio de 2015). " [ ANUNCIO ] systemd v221" . systemd-devel (Lista de correo).
↑ Corbet, Jonathan (2014-01-13). "La presentación de kdbus" . LWN.net .
↑ "Documentación/kdbus.txt (del conjunto de parches inicial)" . LWN.net . 4 de noviembre de 2014.
↑ Corbet, Jonathan (13 de enero de 2014). "La presentación de kdbus" . LWN.net . Consultado el 11 de abril de 2014 .
↑ Kroah-Hartman, Greg (13 de abril de 2015). " [ GIT PULL ] kdbus para 4.1-rc1" . linux-kernel (Lista de correo).
↑ Corbet, Jonathan (22 de abril de 2015). "El accidente del autobús kdbus" . LWN.net . Consultado el 29 de junio de 2015 .
↑ "Conferencia magistral: Charla informal con Greg Kroah-Hartman, miembro de la Linux Foundation" . YouTube . 18 de octubre de 2016. Archivado del original el 21 de diciembre de 2021.
↑ "Enlaces D-Bus" . FreeDesktop.org . Consultado el 5 de enero de 2015 .
Hispanopedia Wiki
