De entre todas las polémicas sobre Systemd sigue sobresaliendo la relacionada con Debian, pero últimamente se ha hablado de la integración de dbus en el kernel bajo el nombre de kdbus. Y junto con kdbus, ha surgido la inevitable discusión sobre la barbaridad que es meter dbus en el kernel, que dbus es una cosa maloliente de escritorio, Linux se está alejando de Los Sagrados Principios Unix, etc etc.
Pero son discusiones sin sentido: kdbus no es una mala idea.
Empezaré reconociendo que, en sus inicios, yo también fui de los que odió la proliferación de dbus, por tener ese olor a software redundante del que podríamos librarnos si se hicieran las cosas como es debido. Sin embargo basta informarse un poco (este vídeo/diapositivas de una charla de Lennart Poettering es muy recomendable) para comprender que su propósito es necesario, se trata de un tipo de IPC de alto nivel disponible en muchos otros sistemas operativos -algunos de ellos microkernels- que no puede ser sustituido por los mecanismos de IPC tradicionales.
Para suplir esa carencia nació dbus, que surgió como un intento de Gnome de librarse de Bonobo e imitar el DCOP de KDE, y que finalmente incluso KDE acabó usando en KDE 4. ¿Pero por qué incluir kdbus en el kernel, en lugar de seguir usando dbus el demonio dbus en espacio de usuario?
En parte, la respuesta es que dbus es bastante ineficiente: Un mensaje dbus de una aplicación a otra requiere copiar los datos y cambiar de contexto de la aplicación al demonio dbus, y este a su vez ha de hacer lo mismo con la otra aplicación. Tampoco es posible tener comunicación dbus desde el arranque del sistema, hay que esperar a que se arranque el servicio, y no está bien integrado con los mecanismos de seguridad del kernel.
En realidad, el kernel es el sitio donde se deben implementar esta clase de cosas: tuberías, FIFOs, sockets Unix, pila TCP/IP, IPC de System V, etc; todos están implementados en el kernel, y en muchos casos lo están por la simple razón de que son muy utilizados y es conveniente hacerlo así. Podría mantenerse dbus en espacio de usuario, pero también se puede implementar la pila TCP/IP en espacio de usuario, y hay razones para no hacerlo. Hay que hacer notar que incluso algunos microkernels implementan sistemas IPC similares dentro del kernel, precisamente porque el IPC entre procesos es su fundamento. Así que creo que las alarmas por kdbus están injustificadas.
No solo eso... es que la parte que esta en el núcleo es bastante reducida. Tan solo hay las primitivas para que ambos procesos puedan enrutar datos, igual que lo hace una tubería o un socket (por supuesto, con funcionalidades a mas alto nivel, como el suscribirse a una señal). Pero el manejo del "payload" sigue haciéndose en cada extremo, en espacio de usuario.
ResponderEliminarEn BeOS, por ejemplo, la comunicación entre procesos a nivel de kernel era mediante paso de mensajes (aparte de los mecanismos tradicionales de IPC) habiendo dos mecanismos: uno mediante un sistema conocido como 'ports' y otro más básico en el que directamente podías enviar un mensaje a un hilo de ejecución.
ResponderEliminarY fue precisamente por estos mecanismos de comunicación a tan bajo nivel por los que la interfaz de BeOS era tan 'responsive'; aparte, claro, de que la comunicación entre procesos era mucho más sencilla para el desarrollador una vez que entendías el concepto (y tenías cuidado con la sincronización de los hilos, eso sí).
Incluso en Android han tratado de hacer algo similar con su módulo de kernel de OpenBinder (hay que recordar que Android tiene a varios ingenieros de Be en su equipo). De hecho, no sé por qué no se ha planteado en ningún momento incluir OpenBinder en la rama principal del kernel, aunque he de reconocer que, mientras haya un sistema de comunicación que no sean los clásicos, casi me valdría cualquiera. Creo que kdbus va a ser un buen estímulo para mejorar sustancialmente el kernel y para mejorar la vida de los desarrolladores de aplicaciones.
¿Habrá nuevo post con http://softlibre.barrapunto.com/softlibre/14/02/14/188219.shtml?
ResponderEliminarNo creo, no hay mucho que decir al respecto.
EliminarHombre, es un cambio importante, ¿no? Muy importante. Y el tema de Ubuntu, que deja Upstart
EliminarSi, pero no es un tema del que pueda decir gran cosa. Pero ahora recuerdo que tengo un post a medio hacer sobre sysvinit, en el que podré mencionar el tema de lado
Eliminar