То что он обращается к одному только Линусу - это прекрасно. То что он спрашивает мнения о патче, который Greg may or may not send - прекрасно вдвойне.
In summary, I think that a very high quality implementation of the kdbus concept and API would be a bit faster than a very high quality
userspace implementation of dbus. Other than that, I think it would
actually be worse. The kdbus proponents seem to be comparing the
current kdbus implementation to the current userspace implementation,
and a favorable comparison there is not a good reason to merge it.
Короче он считает, что ядерная реализация будет ненамного быстрее юзерспейсной, а значит она не нужна.
не просто ядерные девелоперы, а Правильные Ядерные Девелоперы. А greg k-h — хоть и Ядерный Девелопер, но Неправильный, потому что шлёт патчи с Фичами, Которых Не Должно Быть В Ядре, вместо того, чтобы Заниматься Чем-Нибудь Полезным.
А ничего, что gdbus — это клиентская часть, а kdbus — серверная? «Не нужно мерджить сервер, потому что старый клиент медленный, а новый и быстрый я не осилил собрать.»
Я каждый раз удивляюсь :D Чувак, нет смысла совать быстрый сервер в ядро, если клиенты тормозные.
Были бенчи. Прямо в том сраче про pull-request. Искать надо. А вообще, если передавать 1 байт одному слушателю, то разницы не заметят. Тут другое. Может даже не в скорости. А в возможности передавать нормально относительно большие объёмы данных (>100к) для которых при получении не надо копировать эти данные для каждого процесса. Из-за ограничений по скорости разработчики стараются через d-bus передать только метаданные, а данные передавать другими методами.
Я так понимаю, что kdbus боятся только из-за того, что поддержку kdbus реализовали только в systemd? Вообще-то патчи для поддержки kdbus есть уже в стандартном dbus.
Скорость тут - не главное. Проблема в том, что если всё подряд пихать в кернелспейс, то критичность уязвимостей возрастает в разы, поскольку уязвимым становится уже само ядро, что не позволяет быстро локализовать такие уязвимости и повышает убытки. Возможно, это одна из причин, почему тот же accel-pptp не смогли впихнуть в основную ветку.
postgre передаёт «от себя». А dbus получает сообщение, обрабатывает и передаёт другим процессам по тому же сокету.
UNIX domain sockets умеют accept(). Так что нет, технически это уже другой сокет. Ну и да — postgresql умеет работать с несколькими клиентами. Пока никто не умер.
Если смотреть kdbus: тут нету демона как такового. Сообщения идут «напрямую». Есть только демоны автозапуска, мониторинга и управления шинами. Если нужны. Но они просто подключены к шине, через них не проходят все сообщения.
Если kdbus даст новые лазейки в ядро для вредоносного кода, то kdbus не нужен априори, даже если производительность вырастет многократно. Но факт в том, что нифига kdbus не ускоряет, а быстрый он только как вещь в себе.
Относительно большие объёмы данных гонять прямиком через ядро? Они там совсем упоролись. Ну пусть тогда и приложения все в кернелспейс перенесут. Долой безопасность! Зиг-хайль-редхат!
Если смотреть kdbus: тут нету демона как такового. Сообщения идут «напрямую». Есть только демоны автозапуска, мониторинга и управления шинами. Если нужны. Но они просто подключены к шине, через них не проходят все сообщения.
Я понимаю, как работает kdbus. Вопрос в том, так ли это необходимо. Потому что судя по этому: https://lkml.org/lkml/2015/3/18/657 kdbus медленнее UDS.
Он дает прирост скорости и уход от старого демона. Все вопросы к тому, как он это делает и не проще ли то же самое сделает в интерфейсе. Потому что на generic IPC это не тянет.
Я считаю, что в юзерспейсе такие штуки проворачивать безопаснее. Особенно если прирост к скорости не особо высокий. И вообще вопрос скорости тут должен быть второстепенный и вставать принцип «не тащить в ядро что-либо без необходимости».
Вот-вот. Как раз и нужен generic IPC. Вот только как ещё передавать сообщения между процессами. Понятно, что есть много механизмов. Те же unix sockets. Но не будут же приложения создавать сокет на каждый процесс. Да и имена сокетов не могут быть одинаковы. Sharemem - тоже не вариант. Какие варианты есть ещё?