kdbus: to merge or not to merge

То что он обращается к одному только Линусу - это прекрасно. То что он спрашивает мнения о патче, который Greg may or may not send - прекрасно вдвойне.

Ага. Знаешь, когда ядерные девелоперы начинают паниковать — это признак того, что что-то идет не так.

Ah, a preemptive pull request denial, how nice.

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.

Короче он считает, что ядерная реализация будет ненамного быстрее юзерспейсной, а значит она не нужна.

Надеюсь можно будет сделать CONFIG_KDBUS=n? А еще лучше, чтобы так было в defconfig.

интересно, увидим ли мы пресловутое «show me the code» в ответ

kdbus <...> purports to solve <...> performance

I think that the performance issues should be solved in userspace — gdbus performance is atrocious

А ничего, что gdbus — это клиентская часть, а kdbus — серверная?

«Не нужно мерджить сервер, потому что старый клиент медленный, а новый и быстрый я не осилил собрать.»

не просто ядерные девелоперы, а Правильные Ядерные Девелоперы. А greg k-h — хоть и Ядерный Девелопер, но Неправильный, потому что шлёт патчи с Фичами, Которых Не Должно Быть В Ядре, вместо того, чтобы Заниматься Чем-Нибудь Полезным.

А ничего, что gdbus — это клиентская часть, а kdbus — серверная?
«Не нужно мерджить сервер, потому что старый клиент медленный, а новый и быстрый я не осилил собрать.»

Я каждый раз удивляюсь :D Чувак, нет смысла совать быстрый сервер в ядро, если клиенты тормозные.

Вторую часть моей реплики-пересказа ты проигнорировал.

Она нерелевантна, потому что dbus тоже тормозит :D

Ты хотел сказать «sd-bus»? Кто бенчил?

gdbus performance is atrocious
а новый и быстрый я не осилил собрать

Т.е. новый клиент быстрый сам по себе, без kdbus?

«У нас есть ТАААКИЕ торпеды, но мы их вам не покажем» - т.е. «У нас есть ТААКИЕ оптимизации в юзерспейсе, но без ядра мы их не реализуем!»

Мы не про библиотеки, мы про сам dbusd.

Я уж не знаю, про что «вы», но тогда все упоминания gdbus тем более нерелевантны, потому что это клиент.

Я уж не знаю, про что «вы», но тогда все упоминания gdbus тем более нерелевантны, потому что это клиент.

Почему? Клиенты тормозят, серверы тормозят, библиотеки тормозят, а присунуть хотят в ядро. Отличное решение проблемы, чо.

Новый клиент быстрее, чем старый (при том же сервере).

kdbus быстрее, чем dbus-server (при том же клиенте).

sd-bus умеет разговаривать с kdbus нативно, а не через прокси.

Так понятно? Быстрый/медленный — не дискретное состояние.

kdbus быстрее, чем dbus-server (при том же клиенте).

Перепишите dbus-server и будет всем счастье. Где бенчмарки, что этого сделать нельзя? :)

Hi Linus

Можно еще было к уборщице обратиться или в спортлото. Простите, но мейнтейнером стейбл-ядра сейчас является Грег.

А причем тут -stable?

dbus-server медленный из-за транспорта.
Точнее из-за кучи переключений контекста.
Особенно, когда объект «слушают» несколько клиентов.

Да, об этом все постоянно говорят, но никто не может предоставить бенчмарков, которые это показывают.

dbus-server медленный из-за транспорта.

А доказать ты это можешь?

Предложите им свой транспорт, который будет быстрее того же kdbus.

И, кстати, kdbus вообще о dbus ничего не знает :-D

Надеюсь можно будет сделать CONFIG_KDBUS=n?

А потом systemd начнет жестко зависеть от kdbus.

Были бенчи. Прямо в том сраче про pull-request. Искать надо.
А вообще, если передавать 1 байт одному слушателю, то разницы не заметят. Тут другое. Может даже не в скорости. А в возможности передавать нормально относительно большие объёмы данных (>100к) для которых при получении не надо копировать эти данные для каждого процесса. Из-за ограничений по скорости разработчики стараются через d-bus передать только метаданные, а данные передавать другими методами.

Уже же. В этом треде по ссылке есть.

А потом systemd начнет жестко зависеть от kdbus.

Уже же.

Еще нет. Он будет использовать kdbus, если она есть, но пока может работать и без нее.

Я так понимаю, что kdbus боятся только из-за того, что поддержку kdbus реализовали только в systemd? Вообще-то патчи для поддержки kdbus есть уже в стандартном dbus.

Я так понимаю

Ты неправильно понимаешь. По ссылке Andy Lutomirski по пунктам изложил в чём проблемы с kdbus.

Были бенчи. Прямо в том сраче про pull-request. Искать надо.

Ссылку сестра, ссылку.

Из-за ограничений по скорости разработчики стараются через d-bus передать только метаданные, а данные передавать другими методами.

Почему-то тот же postgreqsql передает кучу данных через unix socket и ничо. А dbus не может.

postgre передаёт «от себя». А dbus получает сообщение, обрабатывает и передаёт другим процессам по тому же сокету.

Чем раньше - тем лучше. Линус Торвальдс просто пошлёт подальше таких мержельщиков за сырой код.

Скорость тут - не главное. Проблема в том, что если всё подряд пихать в кернелспейс, то критичность уязвимостей возрастает в разы, поскольку уязвимым становится уже само ядро, что не позволяет быстро локализовать такие уязвимости и повышает убытки. Возможно, это одна из причин, почему тот же accel-pptp не смогли впихнуть в основную ветку.

Всё проще. Объективная реальность такова, что kdbus - удел мудаков.

postgre передаёт «от себя». А dbus получает сообщение, обрабатывает и передаёт другим процессам по тому же сокету.

UNIX domain sockets умеют accept(). Так что нет, технически это уже другой сокет. Ну и да — postgresql умеет работать с несколькими клиентами. Пока никто не умер.

Если смотреть kdbus: тут нету демона как такового. Сообщения идут «напрямую». Есть только демоны автозапуска, мониторинга и управления шинами. Если нужны. Но они просто подключены к шине, через них не проходят все сообщения.

Если kdbus даст новые лазейки в ядро для вредоносного кода, то kdbus не нужен априори, даже если производительность вырастет многократно. Но факт в том, что нифига kdbus не ускоряет, а быстрый он только как вещь в себе.

DBus такое дерьмо, если честно, но от него реально много что зависит.

Не думаю, что будет сильная разница в производительности.

Относительно большие объёмы данных гонять прямиком через ядро? Они там совсем упоролись. Ну пусть тогда и приложения все в кернелспейс перенесут. Долой безопасность! Зиг-хайль-редхат!

Если смотреть kdbus: тут нету демона как такового. Сообщения идут «напрямую». Есть только демоны автозапуска, мониторинга и управления шинами. Если нужны. Но они просто подключены к шине, через них не проходят все сообщения.

Я понимаю, как работает kdbus. Вопрос в том, так ли это необходимо. Потому что судя по этому: https://lkml.org/lkml/2015/3/18/657 kdbus медленнее UDS.

Для такого протокола просто противопоказано иметь возможность передавать относительно большие объёмы данных.

Как будто через unix socket кучу данных не гоняют. Или через тот же sharemem.

Вообще-то большие объёмы там не передаются. Передаётся ссылка на буфер с данными. Или memfd.

Ну а зачем тогда соизмеримые объёмы данных гонять через dbus? По факту сейчас kdbus не даёт ничего кроме потенциальных проблем.

Он дает прирост скорости и уход от старого демона. Все вопросы к тому, как он это делает и не проще ли то же самое сделает в интерфейсе. Потому что на generic IPC это не тянет.

s/интерфейсе/юзерспейсе/

Я считаю, что в юзерспейсе такие штуки проворачивать безопаснее. Особенно если прирост к скорости не особо высокий. И вообще вопрос скорости тут должен быть второстепенный и вставать принцип «не тащить в ядро что-либо без необходимости».

Ммм... Нет. Идея прекрасная, на самом деле. Сделать UDS, только лучше. Реализация просто отстой полный.

Вот-вот. Как раз и нужен generic IPC. Вот только как ещё передавать сообщения между процессами. Понятно, что есть много механизмов. Те же unix sockets. Но не будут же приложения создавать сокет на каждый процесс. Да и имена сокетов не могут быть одинаковы. Sharemem - тоже не вариант. Какие варианты есть ещё?

В QNX, Dragonfly BSD, OS X и прочих есть кошерные IPC в ядре. В plan9 тоже. Мир на лялексе не заканчивается.