Ай да Linux!

Текст новости (взято с ЛОР):
Разработчики из компании Collabora представили проект kdbus, в рамках которого создан экспериментальный прототип шины для межпроцессного обмена сообщениями D-Bus, работающий на уровне Linux-ядра. Встраивание D-Bus в ядро позволило существенно повысить производительность за счет уменьшения числа копирования областей памяти и минимизации числа переключения контекста между ядром и процессом-демоном, работающим на прикладном уровне. В kdbus для отправки сообщений реализован новый тип сокетов AF_DBUS, который напоминает Unix-сокеты и позволяет доставлять сообщения приложению-получателю напрямую, без задействования процесса-посредника (dbus-daemon). Изменения внутренней структуры организации обмена сообщениями не заметно для конечных приложений, так как они используют функции библиотеки libdbus, внешний API которой остался неизменен. Текущая реализация kdbus пока полностью не избавилась от необходимости запуска dbus-daemon, который используется для аутентификации и активации D-Bus, драйвер org.freedesktop.DBus также пока реализован только через dbus-daemon.

Измерение производительности утилитой dbus-ping-pong показало, что kdbus оказался быстрее реализации D-Bus на уровне пользователя в 1.8 раз для платформы i386 (тестовое окружение было запущено под управлением KVM) и в 3 раза для платформы ARM (использовался смартфон Nokia N900). При использовании другого тестового набора прирост производительности был на уровне 26%.

Довольно интересная новость. Но мне кажется, D-Bus пилить надо по другому направлению — именно по юзабилити, и, конечно, по безопасности. В основном, он работает довольно-таки хорошо и без особых затыков, но на новом софте или при нестандартных ситуациях D-Bus ведет себя крайне непредсказуемо (часто, жертва этой технологии сам ССЗБ). Это особенно касается новых версий KDE (4.5.0 — недавний пример). И когда хочешь эту проблему решить, понимаешь, что кроме как поставить патч или другую версию, без ковыряния конфигов, у тебя не получится собственно эту проблему решить.

Давайте рассмотрим ситуацию. Что случится в ядром, если D-Bus зависнет на его уровне (что бывает не так и редко). В идеальном случае — SIGTERM 15 (это если зависло конкретно, да), перезагрузка модуля и дело пошло дальше, работа продолжается (хочу отметить, что если dbus-daemon in userspace уничтожить, а после снова запустить, то d-bus уже, считай, не функционирует и, как минимум, надо проделать logout-login). Но ведь есть вероятность зависания ядра именно из-за него (и дело даже не в зависаниях. Любая нестандартная ситуация, любой нехороший запрос может привести к зависанию ядра. Если даже X, а точнее браузер, а точнее какая-нибудь кривая графика в странице может конкретно фризить систему, причем виснет именно ядро, что же говорить о такой вещи как d-bus). Скорость работы — это, конечно, хорошо (особенно для ARM), но я думаю, что в нынешней реализации d-bus ему не место в ядре. Надо его упростить, сделать понятным для хотя бы среднего пользователя. Другой вопрос — безопасность. Если процесс работает на более низком уровне, чем userspace, то теоретически повышаются возможности воспользоваться внутренними уязвимостями технологии и получении прав (повреждений участков памяти, etc) Но это не значит, что его туда (в kernel) нельзя добавить. Модуль можно просто не включать и использовать в userspace. Так что ничего страшного в добавлении этой технологии я не вижу.

Айнур Шакиров/アイヌル シャキロフ。