Первый вариант патчсета для kdbus в целом получил позитивные отзывы от участников коммьюнити. Несмотря на печать сатаны в виде systemd, более технически ориентированные кернель-разработчики начали конструктивное обсуждение, и дело пошло.

Одной из болевых точек является отношение kdbus и Binder, который по описанию является полным аналогом D-Bus, но от Google. К сожалению, архитектурно он сильно отличается. Но еще более удивительно то, что несмотря на то, что вся система Android построена на базе Binder, его разработка заброшена, хотя в нем есть известные проблемы с безопасностью.

Изначально Greg KH был негативно настроен по поводу Binder, и небеспричинно, надо отметить. Внезапно его отношение не то, чтобы принципиально поменялось, но значительно изменилось. Он неожиданно решил включить его в основное дерево (сейчас оно тоже там, но в staging/). Причем аргументировал это тем, что хотя и Binder плохо спроектирован, но он широко используется (во всех Android-устройствах), и поэтому давайте тащить этот субоптимальный код в основные драйверы. Вполне предсказуемо, что реакция была от сдержанно негативной до негативной. Непонятно, зачем Грегу сейчас срочно понадобилось тащить его в ядро, когда даже инженеры Google планируют переписать юзерспейсную библиотеку libbinder под вот-вот появляющийся в ядре kdbus.

Сам kdbus тоже вызвал вопросы, но совершенно другого характера. Уже понятно, что это будет популярной частью ядра, и стоит обсудить ее архитектуру еще раз, чтобы уж не ошибиться так, что ошибка всплывет позднее.

Первым вопросом, породившим обсуждение, стала концепция "credentials", неких параметров доступа, прикреплявшихся к сообщению. С помощью них планируется обеспечить безопасность. Но когда их прикреплять? При открытии соединения или при посылке каждого сообщения? Eric Biederman настроен отрицательно по отношению к проверке прав доступа в момент соединения, т.к. ранее подобный подход в других случаях и в других частях ядра вызывал проблемы. Однако и присоединение credentials в момент отсылки сообщения вызывает проблемы - не получится присоединиться, получить некий security-токен для некоей операции, и сбросить права доступа, сохранив право на ту операцию. Выбор того или другого варианта обусловливается практическими вариантами применения kdbus, а пока из потребителей этой шины есть лишь systemd (ну и Google, как перейдет на него).

Необходимо обсудить и то, какая информация должна быть послана в credentials. Обязательно ли, например, включать командную строку приложения?

Вызвала дискуссию и ситуация с именами для регистрации. Глобально видимые имена, и их использование в контейнерах приведет к тому, что придется ввести иерархическую структуру, хотя в самих именах нет ничего иерархического (приложение foo никак не соотносится к приложению bar, запущенному в том же или другом контейнере). Одновременно хочется, чтоб приложения могли регистрироваться, но не могли регистрировать на себя "чужие" имена. От этих решений зависит и организация узлов в /dev - будет ли она иерархической, или организованной неким иным образом.

В целом можно сказать, что kdbus был принят разработчиками ядра крайне благожелательно. К сожалению, можно видеть, что слишком много архитектурных решений необходимо обсуждать отдельно, прежде, чем kdbus будет в ядре. Так что если вы, как, например, и мы, ожидаете kdbus в ближайших версиях, то вы будете разочарованы.

Вообще, можно начинать уже переписывать ПО под использование D-Bus, что будет хорошим вариантом. К сожалению, помимо вполне верных утверждений о неторопливости D-Bus по сравнению с альтернативными вариантами шин, про нее еще и рассказывают, что она переусложненная. Нужно сказать, что несмотря на кажущуюся простоту, задача создания шины данных непростая. Но на самом деле, сложность D-Bus не распространяется на API разработчика-пользователя. Lennart Poettering попытался упрощенно рассказать о том, как устроен API D-Bus с т.з. программиста на ANSI C. Будем надеяться, что это поможет разобраться в D-Bus начинающим. Конечно, использование современных языков, а не дореволюционного ANSI C, заметно упрощает использование шины, так что выбирайте правильные языки и тулкиты!


Разработчики systemd закончили с kdbus и планируют дальнейшую экспансию