kdbus и systemd

Ещё никак не поддерживается. Его ещё не смерджили в ядро.

А принцип работы kdbus состоит в том, что в ядро впихивается транспорт (этакая абстрактная шина общего назначения), а сам процесс systemd берёт на себя роль, примерно напоминающую сегодняшний dbus-daemon: управляет правами доступа, маршалингом данных и так далее. Но все «тяжёлые» действия делает ядро (и делает это гораздо более эффективно, чем теоретически можно сделать в юзерспейсе), за счёт чего, собственно, и достигается прирост в скорости.

А приложения общаются с systemd через отдельную библиотеку (sd-bus), примерно напоминающую libdbus-1.

Но это еще нужно будет переписывать приложения, чтобы они использовали kdbus вместо dbus?

Да. Будет слой совместимости (точнее, уже есть), но он вносит значительный оверхед.

Вот стоит у меня systemd, а значит только он единственный является этаким окном в dbus? Или dbus-daemon тоже при делах?

На данный момент при делах только dbus-daemon, потому что kdbus ещё не готов. А впоследствии будет только systemd.

Но dbus-daemon'ом рулит получается именно systemd и впоследствии обычным обновлением в раче dbus по идее должен удалится и на его место встанет kdbus?..

dbus-daemon'ом может рулить кто угодно — это непринципиально. В текущей ситуации systemd его лишь запускает. А впоследствии — да, dbus-daemon исчезнет, и его функции возьмут на себя systemd и ядро.

Что будет оптимальнее: одна программа, которую можно вызвать через dbus, или 5 раздробленных и независимых друг от друга кусков прежней программы, которые вызываются по отдельности? Некоторые куски просто вызываются с получением успешности выполнения, а от некоторых будет требоваться результат выполнения. Много чего интересного узнал о закулисной игре линукс систем, что уже самому захотелось воспользоваться этим на практике..

Понятия не имею. Зависит от того, что тебе нужно и как связаны между собой эти куски... Помни —

If you try to deliver both at once you have to also deliver a way of switching between the two.
Now you have three moving parts instead of one, which means the failure rate has gone up by a factor of _six_ (three parts, and three interactions).

А вот это интересно. Я думал, что dbus и kdbus - параллельные сущности. Можно где то почитать по поводу отличия в них (как девелоперу)?

PS: Не хотелось бы, так получается ждать пока Qt перенесет свои биндинги на systemd (если перенесут вообще, а не выкинут). К тому же, подобное введение означает, что нужно поддерживать дополнительный legacy код, который еще где то тестировать надо =(

В контексте Qt (если мы говорим об одном и том же) всё хорошо, QtDbus в процессе портирования.

Насчёт почитать — не знаю; я не вдавался ещё в подробности, да и юзерспейсное API на данный момент не до конца документировано/стабилизировано. Но вот тут есть пара текстовых файлов, описывающих, как всё работает (хотя это скорее для того, кто будет писать собственную юзерспейсную реализацию).

В контексте Qt (если мы говорим об одном и том же) всё хорошо, QtDbus в процессе портирования

Да, оно. Хоть это хорошо =)

Но вот тут есть пара текстовых файлов, описывающих, как всё работает

На безбабье и кулачок - блондинка. Сяп, почитаю.

kdbus - Это ipc в ядре. Шина в виде файловой системы. И ей рулить может каждый. Хоть монтируй для каждого приложения свой экземпляр :-) в systemd более-менее dbus похожую userspace обвязку реализовали + dbus proxy. И будут реализации, которые не зависят от systemd (кому надо будет).

Т.е. на системах с systemd с dbus можно общаться только через него? Или можно завязывать свой софт на systemd, а в системах, в которых его нет, всё будет идти через dbus proxy? Или приложение работает напрямую с dbus, а systemd рулит этим dbus, а значит рулит твоей программой и можно не беспокоиться?

И будут реализации, которые не зависят от systemd (кому надо будет).

Замечательно.

И будут реализации, которые не зависят от systemd (кому надо будет).

Фух! На этих словах я выдохнул. А-то уже собрался писать, что Линус бы не пустил в ядро любую мегафичу, если бы ей пользовалась только одна прога %)

dbus-proxy эмулирует поведение обычного dbus-daemon через kdbus. Т.е. Любые старые клиенты смогут с ним работать как и раньше.

Вообще kdbus не в курсе про протокол dbus :-)
kdbus рассчитан на передачу любых данных. Вплоть до файловых дескрипторов.
В systemd реализоана обвёртка просто и dbus-proxy. Видел планы о переводе libdbus и для работы через kdbus (опционально, конечно).
Для gdbus(поддержка dbus в glib) тоже пилят поддержку kdbus(без systemd). На счёт Qt - не в курсе.