Грег Кроа-Хартман (Greg Kroah-Hartman) опубликовал (https://lkml.org/lkml/2015/3/9/340) четвёртую версию патчей с реализацией kdbus, реализованной на уровне ядра Linux надёжной, быстрой и безопасной системы обмена сообщениями, поддерживающей доставку сообщений в режиме точка-точка и в режиме мультикаст (от одного отправителя к группе получателей). Kdbus может использоваться не только для альтернативных реализаций D-Bus, не требующих запуска отдельного демона в пространстве пользователя, но и в виде самодостаточного IPC, например, данная система уже поддерживается в systemd.Система D-Bus является универсальной шиной, нашедшей широкое распространение в дистрибутивах Linux. При этом ключевыми недостатками данной системы, обусловленными реализацией D-Bus в пространстве пользователя, является слишком низкая скорость передачи сообщений и неприменимость для приложений, предъявляющих повышенные требования ко времени задержки доставки сообщений. Из-за высоких задержек D-Bus собственные реализации транспортного слоя используются для передачи данных в PulseAudio, Wayland, во фреймворке аутентификации платформы Tizen (запросы аутентификации, связанные с одним действием в интерфейсе должны отработать без задержек для корректной отрисовки результата).
Реализованный на уровне ядра Kdbus решает данные проблемы и открывает новые горизонты для использования D-Bus. Переход на Kdbus позволит унифицировать разрозненные реализации межпроцессорного взаимодействия и сократить дублирование кода между разными проектами. Kdbus также предоставляет средства для передачи метаданных, что даёт возможность применять идентификацию и аутентификацию для участников обмена данными. Кроме того, kdbus предоставляет общую для всей шины систему последовательной нумерации сообщений, что решает проблемы с упорядочиванием сообщений, переданных по разным каналам.
В четвёртой версии патчей продолжено проведение внутренней реструктуризации и чистки. Пересмотрена и переработана логика работы кво, для защиты от DoS-атак 50% ресурсов теперь всегда резервируется для принимающих уведомления соединений, а остальное отдаётся для удалённых узлов. Задействованы новые функции vfs_iter_write(), kstrdup_const(), kfree_const(), появившиеся в ядре 4.0-rc1. Во время установки прекращено использование второго набора слайсов, что привело к сокращению фрагментации, снижению потребления памяти и упрощению.Из основных достоинств реализации шины kdbus на уровне ядра отмечается:
- Высокая производительность за счёт минимизации переключения контекста процессов, меньшего выполнения операций копирования, сокращения системных вызовов, использования memfd;
- Высокая безопасность из-за исключения влияния пользовательских процессов на содержимое шины и использования механизмов ядра для управления передачей данных, в том числе с возможностью контроля со стороны модулей LSM;
- Более высокая устойчивость к DoS-атакам из-за возможности выделения для отправителя ограниченного временного среза при выполнении ресурсоёмких операций и назначения более высоких приоритетов для важных узлов;- К сообщениям могут быть прикреплены различные метаданные;
- Пригодность для приложений, обрабатывающих большие потоки данных, с возможностью расстановки сообщений в очереди на основании приоритетов и задания глобального упорядочивания сообщений. Например, некоторые разработчики нашли применение в kdbus даже для передачи звука в системе;
- Неподверженность многим состояниям гонки, которые трудно устранить в реализации на уровне пользователя. Например, ситуация отсоединения клиента от шины только при условии отсутствия сообщений в его очереди;
- Возможность мониторинга на уровне ядра. Привилегированные пользователи могут подключиться к потоку сообщений без создания специализированных механизмов в пространстве пользователя;
- Возможность прямой доставки сообщения без помещения в очередь, что удобно при организации обработки запросов активации по шине;- Возможность доступа к шине на ранних и заключительных этапах загрузки, в том числе во время выполнения initrd.
URL: https://lkml.org/lkml/2015/3/9/340
Новость: http://www.opennet.me/opennews/art.shtml?num=41810
Кто запилит kdbus over IP? (мне влом)
> Кто запилит kdbus over IP? (мне влом)вы спрашиваете об этом на опеннете?
>> Кто запилит kdbus over IP? (мне влом)
> вы спрашиваете об этом на опеннете?Есть тут пару талантов, но они тоже ленивые иль занятые. :)
>> Кто запилит kdbus over IP? (мне влом)
> вы спрашиваете об этом на опеннете?А где следовало? На текнете?
тебе ZeroMQ мало или других аналогов?
nntpd?
Из описания по прежнему не понятно, чем этот убер-велосипед лучше чем Binder. К сообщениям могут быть прикреплены метаданные? Не, правда? Честно-честно? Вот уж не ожидал такой убер фичи, в 21 веке-то! Можно производить аутентификацию с помощью этих метаданных-то? Вот это сюрприз! Ай-да молодцы! Глядишь через пару десятилетий какой-нибудь особо продвинутый разработчики ядра прочитает в книжке про подсчёт ссылок и ООП и заживём!!!
Мальчик, ты идиот? kdbus это IPC ака шина, и её головная боль - доставка того, что в неё засунули.
Короча, иди доипись до DARPA почему в IP нет кодека VP9
"Доставка того, что засунули" — это пайп. Подсистема, резервирующая 50% ресурсов под защиту себя от себя слабо подходит под это определение.
Прочтите Робачевского чтоль для начала.
> "Доставка того, что засунули" — это пайп.Ага, а сообщение на опеннет надо отправлять исключительно самоличным формированием кадров эзернета. Использовать готовые реализации TCP/IP и еще HTTP поверх него - гнусное читерство. И вообще, как можно пользоваться протоколами, гробящими 50% скорости?!
>> "Доставка того, что засунули" — это пайп.
> Ага, а сообщение на опеннет надо отправлять исключительно самоличным формированием кадров
> эзернета. Использовать готовые реализации TCP/IP и еще HTTP поверх него -
> гнусное читерство. И вообще, как можно пользоваться протоколами, гробящими 50% скорости?!Да он не о том, а, как я понял, о том, что IPC механизьм занимается парсингом и фильтрацией.
> Да он не о том, а, как я понял, о том, что
> IPC механизьм занимается парсингом и фильтрацией.Так я и говорю - мало кто при отправке сообщения на опеннет почему-то хочет лично делать какой-нибудь fragments reassembly в своей программе и заморачиваться какой там в данный момент window у TCP. Вот ленивые уроды, да?! :)
http://kroah.com/log/blog/2014/01/15/kdbus-details/
Хорошая статья, жаль автор мимокрокодил, да ещё и ангажирован до крайности. Binder у него "не гибок", а про поддержку синхронных вызовов в kdbus — "много работы" и "всё и так работает". Ссылки, приводимые в качестве "источников" не содержат _вообще_ ничего по существу, сравните https://lkml.org/lkml/2009/6/25/3. И вообще, интересно было бы услышать мнение велосипедостроителей, почему синхронные вызовы в ядро — норма, а приложения, предоставляющие API должны довольствоваться костылем, скопированный с юзерспейсного IPC.
Например потому, что если умерло или зачудило ядро, и ответа на синхронный запрос нет - это всё, приехали. А если умерло или сошло с ума что-то в юзерспейсе - это нормально. Поэтому в общем случае ядро знать не знает, по каким правилам организовывать синхронность запросов из юзерспейса к юзерспейсу. Если надо - делай это сам по тем правилам, что годятся в твоём случае, благо поверх асинхронных сообщений с уникальными возрастающими ID это делается тривиально. Если нравится обратная ситуация - полюбуйся, как паршиво себя ведёт FUSE когда, скажем, при живом sshfs умерло сетевое соединение и клиент зависает навеки, да так, что с -9 не всегда прибьёшь.
> Если нравится обратная ситуация
> - полюбуйся, как паршиво себя ведёт FUSE когда, скажем, при живом
> sshfs умерло сетевое соединение и клиент зависает навеки, да так, что
> с -9 не всегда прибьёшь.Сейчас на свежем ядре + sshfs-fuse-2.5 при sshfs xxx.xxx.xxx.xxx /net -o directport=7777,reconnect,delay_connect проблемы нет. В mc заходит/выходит в директорию мгновенно, без проблем размонтируется.
> с ума что-то в юзерспейсе - это нормально.Системная шина не имеет права умирать или чудить. End of story. Это critical услуга системы, на которую может (и будет) завязано многое.
именно. А юзерспейс на другой её стороне - вполне может творить что угодно. И если от этого ещё и процесс, инициировавший вызов зависнет - это ни разу не правильно, и у яюра нет libastral чтобы знать, как это разруливать. Поэтому - только асинхронные события на шине, а если нужна синхронность - реализовывать руками, с той логикой обработки нештатных ситуаций, которая подходит для данного случая. Особенно учитывая, что для большинста случаев использования IPC синхронность абсолютно не нужна.
>Например потому, что если умерло или зачудило ядро, и ответа на синхронный запрос нет -
>это всё, приехалиесли ядру кирдык, какой смысл спасать всё остальное? разве в userspace что-то сможет вообще работать при нерабочем ядре?
> если ядру кирдык, какой смысл спасать всё остальное?Некоторым нравится гальванизировать трупы.
Ну так о том и речь. Поэтому синхронные вызовы - к ядру - норма, а вот к юзерспейсу - не норма ни разу.
> Поэтому синхронные вызовы - к ядру - норма, а вот к юзерспейсу - не норма ни разу.Как мне нравятся ваша безапелляционность и уверенный тон. Кроа-Хартман, перелогиньтесь.
> Из описания по прежнему не понятно, чем этот убер-велосипед лучше чем Binder.Да не чем, они просто про Binder невкурсах, да и NIH дает о себе знать.
Семён Семёныч.
D-Bus появился раньше
>особо продвинутый разработчики ядраСлава особо продвинутому разработчикам ядра!
>kdbus, надёжной, быстрой и безопасной системыВот что за мода пошла писать про велосипеды такое? Кто-то гарантирует их стабильную работу, производительность и безопасность? Проводились какие-то тесты и замеры? Что вяленый, что системд, что этот.
Если сравнивать с d-bus, то вполне возможно, но вряд ли обгонит pipe/fifo ;)Возможно и получится что толковое, но вот для аудио и уж тем более для видео лучше использовать что-то более специализированное.
дык для аудио оно и не предназначено, эта штука например что нотификейшен в трей послать иди к другой проге. Вообщем на большее чем нотификэйшен оно не рассчитано.
Боюсь не все это понимают:> некоторые разработчики нашли применение в kdbus даже для передачи звука в системе
В предыдущий обсуждениях, кто-то уже спрашивал про видео ...
Это печально
> В предыдущий обсуждениях, кто-то уже спрашивал про видео ...Ты еще подивись от того что люди офигели и по TCP/IP оказывается видео нынче смотрят.
> Ты еще подивись от того что люди офигели и по TCP/IP оказывается
> видео нынче смотрят.Речь об не сжатом звуке/видео - всего-то 180MB/s ;)
> Речь об не сжатом звуке/видео - всего-то 180MB/s ;)C учетом того что бандвиз оперативы у мало-мальски современных компов с 2-4 interleaved контроллерами памяти нынче легко превышает 10 гигз, 180Мб/сек не такая уж и большая величина. И да, а иксы, норовящие подобное через сетевой стэк вдувать - это как бы ничего, вас не смущает? :)
>> Речь об не сжатом звуке/видео - всего-то 180MB/s ;)
> C учетом того что бандвиз оперативы у мало-мальски современных компов с 2-4
> interleaved контроллерами памяти нынче легко превышает 10 гигз, 180Мб/сек не такая
> уж и большая величина.Вот это и пугает - обязательно найдутся те, кто подобное сделает и скажет "у меня на 8-и ядрах и 16GB ничего не тормозит, у кого тормозит - пусть апгрейдится". Бессмысленная трата ресурсов сейчас стала нормой, налепят десяток прослоек между десятком фреймворков и мнят себя великими программистами, использовавшими все новейшие "технологии".
> И да, а иксы, норовящие подобное через
> сетевой стэк вдувать - это как бы ничего, вас не смущает?
> :)Ну что этот номер не пройдет они быстро осознали и прилепили кучу расширений для прямой работы :)
А что тут понимать или не понимать? Будет готово - будет видно, если подойдут параметры (да - пропускная способность, нагрузка и прочее - в том числе, но также - удобство и пригодность под задачу) - то, может, и видео будет лчерез kdbus летать, а может - окажется вообще универсальным API.
Сейчас уже большая часть софта построена через кучу прослоек, будет еще одна, а потом думаешь как раньше в 3dsmax на 32MB работал, а теперь на 256MB хорошо если текстовый редактор сильно тормозить не будет. Без толку тратится куча ресурсов. Да бывают ситуации когда подобные решения могут быть оправданы, но это единичные случаи. У меня на десктопе и ноуте нет d-bus и как не странно необходимости в оном не чувствую.
> и ноуте нет d-bus и как не странно необходимости в оном не чувствую.А у нокии d-bus был на девайсах с 64-256 мегов памяти. И ничего, им там хватало и пользовались по делу. А ноутом вы пользуетесь в стиле мамонтов наверняка. Даже к беспроводной сетке в кафешке поди не сможете прицепиться быстренько, etc. А то network manager с wpa supplicant'ом через dbus перекидываются как-то. Зато юзеру удобно выбрать сетку из списка и тут же завалиться в нее, одним тычком мышки/точпада.
>> и ноуте нет d-bus и как не странно необходимости в оном не чувствую.
> А у нокии d-bus был на девайсах с 64-256 мегов памяти. И
> ничего, им там хватало и пользовались по делу.Уже сказал - если действительно по делу, то я только за. Другое дело, что реально нужны подобные вещи очень редко.
> А ноутом вы
> пользуетесь в стиле мамонтов наверняка. Даже к беспроводной сетке в кафешке
> поди не сможете прицепиться быстренько, etc. А то network manager с
> wpa supplicant'ом через dbus перекидываются как-то. Зато юзеру удобно выбрать сетку
> из списка и тут же завалиться в нее, одним тычком мышки/точпада.Отвечал уже:
http://www.opennet.me/openforum/vsluhforumID3/100356.html?#434У wpa_suplicant четыре интерфейса для управления: socket, pipe, udp, d-bus. Родной wpa_gui работает через socket. Реализация socket - 18.6K, udp - 13.8K, d-bus - 388K.
Шина - это копеечные затраты ресурсов. И обрати внимание - я ж спецально оговорил - "если подойдут параметры". Просто потребление ресурсов - это только один из факторов, влияющих на пригодность или непригодность решения.У меня самого D-Bus нет (откуда ему быть - без DE, пульсов и прочего подобного?). Потому что для моих нужд больше подходит софт, авторы которого курили меньше конопли, чем авторы третьегнома или Потеринг. Ну, или конопля у них была лучше ;-)
Но я очень хорошо представляю архитектуру, где практически всё бы работало через него, а до тех же пайпов разве что оптимизировались бы автоматом отдельные частные случаи. Что, в частности, означало бы, что у ЛЮБОЙ гуёвой софтины гарантированно есть программный интерфейс, который может не меньше, чем гуй. Причём стандартизированный, в отличие от миллиона форматов сокетов и вывода в stdout. И да, я бы очень хотел заменить POSIX на такую штуку.
И если ради такой унификации окажется, что видео тоже через D-Bus летает (и, соответственно, его можно процессить как угодно, к примеру) - то и хрен бы с ним, если затраты ресурсов будут приемлемые.
> Но я очень хорошо представляю архитектуру, где практически всё бы работало через
> него, а до тех же пайпов разве что оптимизировались бы автоматом
> отдельные частные случаи. Что, в частности, означало бы, что у ЛЮБОЙ
> гуёвой софтины гарантированно есть программный интерфейс, который может не меньше, чем
> гуй.Мысль интересная. Но к каждому GUI нужно будет прикрутить управление через эту шину + способ получение элементов (widget) GUI доступных на данный момент. Будут сложности с организацией автомотизированной работы: придется ждать появления новых окон и правильно обрабатывать неожиданно возникшие окна и запросы. Ломаться совместимость будет часто - GUI изменяют чаще, чем cli.
Но главное, что это реально даст? Насколько это решение может быть оправдано и полезно? Будут ли реальные преимущества, против применяемого на данный момент подхода (backend + frontend, backend as lib + frontend)?
> Причём стандартизированный, в отличие от миллиона форматов сокетов и вывода
> в stdout. И да, я бы очень хотел заменить POSIX на
> такую штуку.Для GUI - да. Для cli - нет, так как мы передаем не команды, а данные, закодированные в стандартных форматах. Фактически мы просто передаем файлы. GUI особый случай - так как требует обработки обратной реакции, отсюда и все трудности при попытке автоматической работы с ним. Стоит ли оно того?
> И если ради такой унификации окажется, что видео тоже через D-Bus летает
> (и, соответственно, его можно процессить как угодно, к примеру) - то
> и хрен бы с ним, если затраты ресурсов будут приемлемые.А действительно ли нужна эта унификация? Там, где она реально востребована, уже используются узкоспециализированные решения (jack), попытка заменить их на универсальные приведет к падению производительности и отзывчивости.
> Вообщем на большее чем нотификэйшен оно не рассчитано.Но ведь есть "не-ведерный-дбус". Ну, перепилили бы его, сделали "правильным".
А так, "kdbus" == kernel(space)-desktop-bus. Ура, товарищи, мы тянем части десктопа в ядро!
А есть идеи получше?
> Но ведь есть "не-ведерный-дбус". Ну, перепилили бы его, сделали "правильным".K-H привел вполне разумные аргументы что для юзермода ряд вещей будет делать сложно, а производительность получится плохой. Гугл вон уже binder самопальный наколхозил, не от хорошей жизни явно.
> А так, "kdbus" == kernel(space)-desktop-bus. Ура, товарищи, мы тянем части
> десктопа в ядро!С фига ли системная шина сама по себе - десктоп? Уху ели? Вон в openwrt карманный вариант героя в видe u-bus на роутерах микроскопических. Они в каком месте десктоп? Там видеокарты нету! И памяти - мизер.
>дык для аудио оно и не предназначено, эта штука например что нотификейшен в трей послать иди к другой проге. Вообщем на большее чем нотификэйшен оно не рассчитано.Вот как раз в этом разрезе многим (и мне в том числе) не вполне понятно зачем это вкорячивать в ядро? Просто чтобы зафиксировать как "стандартный интерфейс"? А весь чёс с умным видом про "возросшую производительность" зачем? Там производительности и так для tray notifications с избытком. Нет, я серьезно не понимаю. Обьясните мне кто- то.
> Если сравнивать с d-bus, то вполне возможно, но вряд ли обгонит pipe/fifo ;)Ну да. Вон zmap за полдня весь интернет сканирует на гигабитном канале. Потому что пакеты сам кроит и отсылает влобовую. Но вот почему-то писать по таким принципам браузер или файлокачалку всем уже дико вломак и такие утилсы остаются крайне нишевым развлечением... :)
Вы же не отсылаете мессаги на опеннет прямой компоновкой кадров эзернета? Ну вот и с системной шиной как-то так же. Pipe или fifo не имеют штатно фич характерных для dbus и вообще системных шин. Поверх них можно что-то такое сделать. Но это будет еще более жуткий велосипед, да и убедить всех остальных пользоваться именно им лично вам будет сложновато. А KH пожалуй даже сможет.
спасибо, не надо.
в systemd уже вляпались.
Ну да, то ли дело когда каждый кулсисоп сам городит себе эрзац системы старта, эрзац менеджера регистрации виртуалок, эрзац системной шины и прочая. Чего б вам не пойти в пень и не написать себе эрзац кернела для начала? (ну а мы отдохнем от вас ближайших 10 лет)
Комментарии - наглядная демонстрация некомпетентности критиканов и ретроградов, даже доказывать ничего не нужно.
Ну дык комментарии по делу Шигорин сносит зачастую по политическим причинам (травонулся на почве путинбох), а это дополнительная причина просто троллить
Как пример - оставляет все комменты упоротого линуксофоба иЗеня, только потому что тот тоже поцреотит и удаляет все мои комменты, даже чисто технические (попоболь Шигорина рельефна и обширна, да).
При этом если я пишу те же самые технические комментарии анонимно и через прокси -- не трогает. Такие дела.
Справедливости ради, ты порой лезешь в бутылку совершенно на ровном месте. Ну и нарываешься с политотой. Я конечно понимаю что у грузинов батхерт от того что им по чайнику настучали, но постоянно изливать его на опеннете - явно лишнее...
А внутри кластера будет Kdbus прозрачно работать?
> А внутри кластера будет Kdbus прозрачно работать?Думается написать kdbus2ip и ip2kdbus,... минут на 15-20.
Ага, щазз. Одна из ценных фишек kbus - те самые метаданные и идентификация отправителя. В кластере это, как минимум, надо подвязывать на какие-то директории пользователей или что-то подобное, а что с процессами делать - вообще отдельный вопрос.
> Ага, щазз. Одна из ценных фишек kbus - те самые метаданные и идентификация отправителя.И чо сложного?
> В кластере это, как минимум, надо подвязывать на какие-то
> директории пользователей или что-то подобное, а что с процессами делать -
> вообще отдельный вопрос.бла-бла-бла...
---
В общем, ни одной проблемы не вижу в прикручивании, скажем, к OpenStack, вопрос в другом - нафуя!?
Не смущает, что на другой ноде оригинальные юзер и pid не несут вообще никакого смысла, если не сделать специальную логику по синхронизации этого дела? А это написать - уже ни разу не 15-20 минут. Тут продумать, как это вообще должно мапиться и управляться - и то дольше.
А юзерспейсный работает?
Уважаемые модераторы!
IP адрес сайта opennet.ru зарегистрирован в Санкт-Петербурге, поэтому, я полагаю, на него распространяется российское законодательство.
На аватаре пользователя kurokaze размещен флаг запрещенной в РФ экстремистской организации "Правый Сектор". Чтобы не возникло проблем, порекомендуйте ему изменить аватар.
Уходи.
Это логотип Росбанка
Когда kdbus засунут в ядро, то скорее всего в libdbus добавят kdbus транспорт. Ну и нативные клиенты появятся (тот же systemd).Glib и Qt будут иметь нативную поддержку kdbus.
Вопрос только: Когда? Когда засунут в ядро?
Последние пару лет их туда не брали. Будем надеяться, что и не возьмут.