Грег Кроа-Хартман (Greg Kroah-Hartman) представил (https://lkml.org/lkml/2015/1/16/488) в списке рассылки разработчиков ядра Linux третью версию патчей с реализацией kdbus, надёжной, быстрой и безопасной системы обмена сообщениями, поддерживающей доставку сообщений в режиме точка-точка и в режиме мультикаст (от одного отправителя к группе получателей). Kdbus может использоваться как в самодостаточном виде, например, данная система уже поддерживается в systemd, так и в качестве основы для реализации D-Bus, не требующей запуска отдельного демона в пространстве пользователя.В третьей версии патчей добавлен флаг FS_USERNS_MOUNT, при помощи которого пользователи могут примонтировать собственные обособленные экземпляры kdbusfs. Переписана большая часть кода, связанная с обработкой метаданных, что позволило обеспечить возможность трансляции привязанных к получателям пространств имён. Идентификаторы PID и TID перемещены из KDBUS_ITEM_CREDS в KDBUS_ITEM_PIDS, что дало возможность отслеживать ситуации с повторным использованием PID другим процессом. Прекращена поддержка интерфейса KDBUS_CMD_CANCEL, вместо которого следует использовать CANCEL_FD с ioctl CMD_SEND. Вызов KDBUS_CMD_MSG_SEND переименован в KDBUS_CMD_SEND, а KDBUS_CMD_MSG_RECV в KDBUS_CMD_RECV.
Из основных достоинств реализации шины kdbus на уровне ядра отмечается:
- Высокая производительность за счёт минимизации переключения контекста процессов, меньшего выполнения операций копирования, сокращения системных вызовов, использования memfd;
- Высокая безопасность из-за исключения влияния пользовательских процессов на содержимое шины и использования механизмов ядра для управления передачей данных, в том числе с возможностью контроля со стороны модулей LSM;
- К сообщениям может быть прикреплено больше метаданных;
- Пригодность для приложений, обрабатывающих большие потоки данных, с возможностью расстановки сообщений в очереди на основании приоритетов и задания глобального упорядочивания сообщений. Например, некоторые разработчики нашли применение в kdbus даже для передачи звука в системе;
- Неподверженность многим состояниям гонки, которые трудно устранить в реализации на уровне пользователя. Например, ситуация отсоединения клиента от шины только при условии отсутствия сообщений в его очереди;
- Возможность мониторинга на уровне ядра. Привилегированные пользователи могут подключить к потоку сообщений без создания специализированных механизмов в пространстве пользователя;
- Возможность прямой доставки сообщения без помещения в очередь, что удобно при организации обработки запросов активации по шине;- Возможность раннего доступа к шине, на этапе выполнения initrd.
URL: https://lkml.org/lkml/2015/1/16/488
Новость: https://www.opennet.ru/opennews/art.shtml?num=41478
Почему бы не вынести _это_ в юзерспейс?
> Почему бы не вынести _это_ в юзерспейс?Потому что это в юзерспейсе уже есть и пытаются наоборот из юзерспейс в ядро перенести, так как безопасность, надёжность (race condition в DBus источник многих проблем) и производительность у DBus в юзерспейс никакая.
это не объясняет зачем оно нужно в ядре. ну плохой dbus, значит надо переписать так чтоб был хороший и быстрый. но в ядро-то зачем пихать все подряд.
> но в ядро-то зачем пихать все подряд.Вы же сами ответили
> ну плохой dbus, значит надо переписать так чтоб был хороший и быстрый.
А "хороший и быстрый dbus" в юзерспейсе - это несбыточная хотелка, противоречащая объективной реальности. Типа вечного двигателя. Ну нельзя его сделать. Нель-зя.
> А "хороший и быстрый dbus" в юзерспейсе - это несбыточная хотелка, противоречащая
> объективной реальности. Типа вечного двигателя. Ну нельзя его сделать. Нель-зя.Это ещё почему? Процессор в юзерспейсе медленнее работает?
потому что дбас — дерьмо.
> Это ещё почему? Процессор в юзерспейсе медленнее работает?написано же - "минимизации переключения контекста процессов". Переключения контекста - удовольствие дорогое. Чтобы два разных юзерспейсовских пользовательских процесса "говорили" друг с другом через третий юзерспейсовский процесс (демон управления сообщениями) придется больше переключений сделать (потому что все равно эти три процесса будут с друг другом через какие-то уже существующие ядерные IPC взаимодействовать). А так один из процессов из цепочки исключается, ядро его функции берет на себя
а всё потому, что они пытаются применять шину для того, для чего она не предназначена. господи, если я в тебя поверю, ты ответишь мне, зачем ты создал столько дебилов?
кокой изощрённый способ саморефлексии
>а всё потому, что они пытаются применять шину для того, для чего она не предназначена. господи, если я в тебя поверю, ты ответишь мне, зачем ты создал столько дебилов?Угум, а в ответ получишь: "все вопросы - к эволюции, я ей - только пинка дал".
>>а всё потому, что они пытаются применять шину для того, для чего она не предназначена. господи, если я в тебя поверю, ты ответишь мне, зачем ты создал столько дебилов?
> Угум, а в ответ получишь: "все вопросы - к эволюции, я ей
> - только пинка дал".это у него гнилой отмаз. как вдруг что хорошо получилось — так «славьте меня», а как вдруг что хреново — так это «эволюция виновата». ненене.
>>>а всё потому, что они пытаются применять шину для того, для чего она не предназначена. господи, если я в тебя поверю, ты ответишь мне, зачем ты создал столько дебилов?
>> Угум, а в ответ получишь: "все вопросы - к эволюции, я ей
>> - только пинка дал".
> это у него гнилой отмаз. как вдруг что хорошо получилось — так
> «славьте меня», а как вдруг что хреново — так это «эволюция
> виновата». ненене.Бога со святошами не путаешь? Мало ли чего им там по укурке ладаном привиделось...
> Бога со святошами не путаешь?так он только через них и говорит. напрямую пока не слышал. к счастью, наверное.
>> Это ещё почему? Процессор в юзерспейсе медленнее работает?
> написано же - "минимизации переключения контекста процессов". Переключения контекста
> - удовольствие дорогое.Ух, КЭП, а разработчики plan9 не в курсе. Надо им рассказать.
Что-то мне подсказывает, что если всё делать по уму, то такая высокоуровневая вещь, как dbus, не может проводить много больше времени в переключениях контекста, чем в основной работе.
>> Это ещё почему? Процессор в юзерспейсе медленнее работает?
> написано же - "минимизации переключения контекста процессов". Переключения контекста
> - удовольствие дорогое.И вообще, я бы послушал, что на это скажут разработчики dpdk. А то, может, они зря столько сил вбухивают, что бы всё наоборот из ядра в юзерспейс вынести.
Это не всё подряд. Это просто ещё один механизм IPC. Давно пора.
> ещё один
> Давно пора
> но в ядро-то зачем пихать все подряд.На этот вопрос хорошо описано в списке достоинств в новости. Если кто-то не умеет читать - нет смысла орать на ухо глухому.
>> Почему бы не вынести _это_ в юзерспейс?
> Потому что это в юзерспейсе уже есть и пытаются наоборот из
> юзерспейс в ядро перенести, так как безопасность, надёжность (race condition в
> DBus источник многих проблем) и производительность у DBus в юзерспейс никакая.Ты это так говоришь, будто при переносе кода в ядро вдруг исчезнут race condition. Наоборот, можно будет валить ещё и ядро, если удачно их использовать. Всё то, за что 5 лет поливали грязью венду, стало вдруг "хорошим" и "годным" в линуксе.
> Ты это так говоришь, будто при переносе кода в ядро вдруг исчезнут race condition.Подучите матчасть, тогда у вас и не будет таких глупых вопросов.
Венду поливали грязью 15 лет за реестр и за то, что сейчас творит Поттер в GNU/Linux.
> Венду поливали грязью 15 лет за реестр и за то, что сейчас
> творит Поттер в GNU/Linux.То, что сейчас творит Поттер - это вообще не винда, а BSD. Когда вместе с ядром ставится куча левых прог на все случаи жизни, и хрен чего удалишь без пересборки. Между прочим, BSDшники этим гордятся - все под рукой из коробки.
> То, что сейчас творит Поттер - это вообще не винда, а BSD.То, что сейчас творит Поттер - это вообще не винда, а BDSМ
исправил во имя справедливости!
Исправил на синоним, я бы сказал
kdbus имиет к Поттеру весьма косвенное отношение. Это универсальная основа для всех, кому надо. А заменять разносортицу сокетов, файлов-флагов и черт знает чего ещё давно пора.
>kdbus имиет к Поттеру весьма косвенное отношение. Это универсальная основа для всех, кому надо.Дело в том, что по большому счету это не надо никому, кроме системдэшных хипстеров, которые и начали пропихивать dbus в ведро. Даже в новости написано, что автор этой спичечно-желудевой поделки - Грег КХ, который тоже системдэшный хипстер. Кдбус - это проект системдэшников для системдэшников. Но так как системд не нужен, то не нужен и кдбус.
>А заменять разносортицу сокетов, файлов-флагов и черт знает чего ещё давно пора.
Заменять чем (и вообще, зачем)? Другой разносортицей?
Не надо потому, что нет. Тот D-Bus, что сейчас есть, используется на все свои 100%. Будут новые возможности у ядерного (прежде всего в плане идентификации адресата и скорости) - будут и новые применения. systemd (который, таки ненужен) и так живёт.А заменять - именно стандартной шиной. Которую всегда можно стандартными инструментами просмотреть, запротоколировать, а при необходимости - и воткнуть модуль модификации сообщений. Чтобы странная идея рисовать свой очередной формат обмена через сокеты в голову никому не приходила. Но для этого нужна гарантия, что эта самая стандартная шина будет всегда и везде, в работоспособном состоянии и т.д. По факту в линуксе такую гарантию могут дать только разработчики ядра.
> А заменять - именно стандартной шиной.Понятно дело. Только пропускная способность этой шины всё равно лимитирована кольцевой топологией. Нафиг её в ядро-то засовывать? Тот же sed вполне себе стандартизован, а в ядре его почему-то нет.
Там не такая уж и кольцевая топология. Большинство сообщений летает всё же не броадкастами, а подписчикам. Зато эта топология даёт хорошую реалтаймовую интроспекцию и при нужде - возможность модификации на лету.
> Там не такая уж и кольцевая топология. Большинство сообщений летает всё же
> не броадкастами, а подписчикам.Достаточно одного приложения, шлющего broadcast'ы, чтобы поставить систему раком. Поэтому должны быть ограничения на то, что передаётся. А раз так, то зачем нужно в ядро пихать-то?
> Зато эта топология даёт хорошую реалтаймовую интроспекцию
> и при нужде - возможность модификации на лету.При условиях, что не через ядро (иначе неправильный интроспектор грохнет систему), и поток невелик (интроспектор ведь не многопоточный, а ядер даже у смартфона бывает аж 8 штук!).
> Венду поливали грязью 15 лет за реестрА где у поттера реестр? Коронный вопрос.
>> Венду поливали грязью 15 лет за реестр
> А где у поттера реестр? Коронный вопрос.
> реализация kdbus для ядра Linux
> так как безопасность, надёжностьотлично поделил на ноль. Какие ещё вспомнишь фичи из существующих для чего-либо? Можешь смело продолжать ими свой список.
В юзерспейсе и иксы есть. Может их тоже в ядро...
> В юзерспейсе и иксы есть. Может их тоже в ядро...Так уже X в ядре есть - правда полузакрытая платная разработка ,вроде называется микроX или миниX .Думал разработка закрылась нет еще шевелятся (смотрел в октябре прошлого года) заказы у них есть ,правда не много .Совместимость с классическими X не полная ,приложения нужно собирать под их версию X и либ,но и правда маленькое и шустрое -600кб модуль ядра ,3,5 либы ,из класических минусов нет сетевой потдержки ,за счет чего сделали гораздо шустрее .
> В юзерспейсе и иксы есть. Может их тоже в ядро...Ну как бы ядро и само нынче по минимуму рисовать может. См. drm и kms.
> В юзерспейсе и иксы есть. Может их тоже в ядро...http://filemare.com/browse/131.114.56.15/pub/Linux/fbui-0.11...
FramebufferUI 0.11.2FBUI is a small, fast in-kernel GUI windowing system for Linux.
FramebufferUI
FBUI is a small, in-kernel graphical user interface for Linux. It permits you to put windows in each framebuffer-based virtual console, to read keyboard input, track a mouse pointer, and respond to typical GUI events. Each process may have more than one window.
· FBUI exists to reduce the software bloat that plagues modern operating systems. It does this by virtue of its being a simple windowing system in the form of a small, 32 kilobyte driver which for some purposes may be quite sufficient. Liberation from bloat is desirable for a number of reasons that I explain in the Philosophy section.
· FBUI exists to assists people who are prohibited from using X Windows because they are using resource-limited platforms such as old computers and embedded devices. On these, X is an impossible burden. However a vanilla framebuffer is often too primitive. FBUI is "just right", and libfbui makes using FBUI even easier to use by providing abstractions and additional functions.
· FBUI exists to correct a flaw in the Linux operating system architecture. The traditional GUI -- X Windows -- is unlike any other subsystem of Linux in that the hardware-accelerated video drivers it uses are located within the X server, outside the kernel. Notice: normally Linux drivers and vital subsystems such as keyboard, USB, filesystem, serial I/O, et cetera are all located inside the kernel. FBUI simply puts the graphics UI driver where it belongs: inside the kernel with all the other drivers.Here are some key features of "FramebufferUI":
· Unlike X Windows, FBUI supports windows on every virtual console.
· Each program may have more than one window.
· Overlapping windows are currently not supported, but I am adding support for them now.
· There is no concept of parent and child windows.
· Programs can receive raw keystrokes from FBUI which they can then translate to ASCII using a library routine. One process is permitted to have keyboard focus.
· Each process accesses its windows completely independently of all other processes.
· In X, the library has to send all drawing commands to the server process, which puts them in a queue and executes them whenever it has a chance. If the server is busy, or another X application is flooding the queue, then an X application must wait. Not so with FBUI, where the ioctl takes a list of drawing commands that go directly to be executed if the window is visible and irregardless of what any other window is doing. To further ensure the above concurrency is the norm, use of semaphores within FBUI to access common data is made as brief as possible.
· Each virtual console can have its own optional window manager process. But this is not necessary and for instance many programs that I've written are also designed to run in standalone mode, examples being fbcalc, fbview, fbscribble, and the my FBUI variant of mpeg2decode.
· I'm providing a fairly basic window manager fbwm, but current development is centered on fbpm, which is my panel-based window manager.FBUI offers a sufficient set of drawing routines:
· draw point, line, horizontal line, vertical line, rectangle
· draw text (8-bit)
· window clear, fill rectangle, clear rectangle
· copy area
· put pixels (3-byte RGB, and 4-byte (unsigned long) RGB, and native)
· wait for event
· poll for event
· the window manager process can hide and unhide other processes' windows, move, resize, re-expose, and delete windows.
· read point
· FBUI is currently written for 8,16,24, and 32-bit directcolor and truecolor. I am presently adding 4-bpp VGA. (Note : on VESA, I've done testing for 24 bit only.)Sample programs provided (I suppose I've gotten carried away) :
· panel-based window manager (current focus of work)
· conventional window manager
· JPEG+TIFF image viewer
· very simple MPEG playback based on circa 1995 MPEG2 library
· terminal emulator (based on ggiterm)
· load monitor
· "scribbler" drawing program
· analog clock
· simple calculator
· "Start" button program, which invokes fblauncher menu program
· POP3 mail checker
· "to do list" displayer programRequirements:
· FBUI requires kernel 2.6.9. :)
What's New in This Release:
· This release adds overlapping windows and transparent drawing.
Так что, баян дикий, но для кофеварок и холодильников вполне.
> Here are some key features of "FramebufferUI":Это скорее список недостатков.
>> Here are some key features of "FramebufferUI":
> Это скорее список недостатков.Can i see you realization? Benchmarks? Compare key features?
Or you just peace da ball?
> Can i see you realization?Павлик, я в своё время посчитал кол-во "графических систем", сделанных под Linux - их около десятка. Неужели ты думаешь, что я настолько больной на голову, чтобы после этого создавать свой аналог DirectFB?
>> Can i see you realization?
> Павлик, я в своё время посчитал кол-во "графических систем", сделанных под Linux
> - их около десятка. Неужели ты думаешь, что я настолько больной
> на голову, чтобы после этого создавать свой аналог DirectFB?:D +100500
> Can i see you realization? Benchmarks? Compare key features?
> Or you just peace da ball?mgimo finished
>> Can i see you realization? Benchmarks? Compare key features?
>> Or you just peace da ball?
> mgimo finishedйес, йес - э гёрл!
> Почему бы не вынести _это_ в юзерспейс?Пока что есть более важные вещи, которые определенно стоит вынести в юзерспейс раньше - сетевой стек, фаервол, стек блочных устройств (DM, mdraid, LVM).
оу,оу, полегче, давайте еще планировщик процессорного времени в юзерспей вынесем, или даже лучше все ядро как процесс запускать, а какойнить command.com пусть будет ядром, назовем это линукс 98 фор ворк груп. атличная идея. Бил.
Линукс98? Зачем же. Назовём это Хурд.
Генод - в соседней новости. Здесь о линуксе речь. Арихтектура которого уже показала свою эффективность где только можно.
> Почему бы не вынести _это_ в юзерспейс ... весь текст скрытПотому что от костыли _такого_ размера становится только хуже. Впрочем, даже будь такое решение удобным, просто началась бы война вокруг того, чей интерфейс лучше. У ядерного IPC уйма преимуществ, не зря его перым делом реализовали в Android (см. https://lkml.org/lkml/2009/6/25/3) и уже черте сколько лет пилят в Венде.
>У ядерного IPC уйма преимуществТы это так говоришь, будто его там сейчас нет.
>>У ядерного IPC уйма преимуществ
> Ты это так говоришь, будто его там сейчас нет.Высокоуровневого IPC - нет.
А каждый раз велосипедить высокоуровневый протокол поверх низкоуровневого IPC, предназначенного для обмена сырыми данными - обезьянья работа.
>>>У ядерного IPC уйма преимуществ
>> Ты это так говоришь, будто его там сейчас нет.
> Высокоуровневого IPC - нет.
> А каждый раз велосипедить высокоуровневый протокол поверх низкоуровневого IPC, предназначенного
> для обмена сырыми данными - обезьянья работа.Осиль наконец преимущества разделяемых библиотек, школьник.
Их все осилили. И каждый ваяет свой велосипед. А вот эмулировать, скажем, сокеты как-то в голову не приходит, даже если голова совсем больная. Потому что ежу ясно, что эффективнее не будет - максимум можно сверху что-то наворотить, как в ZeroMQ.Вот и kdbus - будет стандартная реализация - больше народу уйдёт от самопала. А самопал в IPC - глупость редчайшая, так как IPC - это о взаимодействии и, соответственно, совместимости.
чем sysv ipc не угодил ?
> чем sysv ipc не угодил ?Тем же чем не угодила отправка сырых кадров эзернета для того чтобы отправить сообщение на опеннет. Да, можно сказать что ну его нафиг - TCP/IP стек в ядре. Нехай программа сама его реализует. Ну вот использовать sysv ipc для того для чего используют dbus - это примерно как отсылать сообщения на опеннет путем компоновки всех необходимых кадров эзернета самолично. Без использования соотв. услуг ядра. Тyпoй пуризм и баранья упертость еще и не до такого доводит.
Вы с ним разбирались? Мало того, что опять неструктурированные блобы гоняет, так еще и буфер очереди совершенно смехотворный.Да и отправителя там не узнать - ни pid, ни uid.
> Вот и kdbus - будет стандартная реализация - больше народу уйдёт от самопала.никто не уйдёт от нормальных реализаций IPC, хотя бы лишь из-за отсутствия этого kdbus для других posix'оподобных ос. Ниша (?)dbus это максимум десктопная интеграция + некоторые стандартные системные задачи, в общем где он и сейчсс спокойно живёт.
Сервисы которым нужен IPC для масштабирования и/или изоляции процессами никто на (?)dbus переводить не будет, это мечты дилетантов.
> никто не уйдёт от нормальных реализаций IPC,"Никто не уйдет от компоновки сырых фреймов эзернета к дерганию вызовов ядра для работы с TCP/IP".
Гуманитарное днище, угомонись уже со своими тупыми аналогиями.
В других ОС будуть использовать dbus. Сюрпрайз. :-)
С головой дружишь хоть немного? Если в других ОС можно использовать сам dbus, то и тут kdbus тоже не нужен ибо вместо него можно использовать dbus.
Первое, где сейчас нужна вменяемая компонентная архитектура - это как раз десктоп. И хорошая изоляция, идентфикация адресата и т.п. для этого абсолютно критичны.А другие POSIX-системы - не смешите. Нет их. Из живого есть ещё макось - но там обычно совсем свой софт. У *BSD ниша только уменьшается, что там осталось? Подыхающий солярис и изолированный мирок AIX?
> А другие POSIX-системы - не смешите. Нет их. Из живого есть ещё макось - но там обычно совсем свой софт. У *BSD ниша только уменьшается, что там осталось? Подыхающий солярис и изолированный мирок AIX?И сколько там процентов у линух-десктопа?
> Вот и kdbus - будет стандартная реализация - больше народу уйдёт от
> самопала.тоже правильно: будет легче детектировать идиотов. в принципе, использование в программе dbus — уже признак нехилого идиотизма. а с kdbus идиотизм вообще будет ядерный.
Не знаю, как ты, а я был бы очень рад, если бы всё, что у меня умеет сейчас управляться через сокеты, начиная с rtorrent того же, умело какие-то более структурированные механизмы. Да и те же нотификации с DBus выглядят куда как логичнее, чем фридесктоповская механика, подразумевающая существование иксов и окна, принимающего сообщения.В сущности, современную систему как раз вокруг такой (ладно, почти такой) шины надо целиком строить, на событийной рахитектуре. От аналога udev, нотификаций DHCP-клиента и прочей системщины до выставления всего пользовательского интерфейса в виде интерфейсов D-Bus, а уже потом - гуя поверх них. Чтобы для всего этого дела возможна была вменяемая единая конфигурация.
разве ж я когда был против идеи нормальной общей шины? но когда мне вместо неё впаривают дбас, я начинаю кусаться. а когда вдобавок говорят, что шина теперь в ядро будет засунута… тут я уже не кусаться хочу, а убивать.
Ну так с реальностью надо дружить. Был бы выбор "DBus или вменяемая шина" - я бы тоже кусался. Но здесь - "DBus или вообще без стандартной шины".Кстати, насколько я помню, kdbus - это не DBus, а довольно обобщённый механизм шины, на нём, пожалуй, и что-то получше, чем DBus, можно сделать. Не уверен, правда, не повлечёт ли это очередной зоопарк.
> Ну так с реальностью надо дружить. Был бы выбор "DBus или вменяемая
> шина" - я бы тоже кусался. Но здесь - "DBus или
> вообще без стандартной шины".нафиг-нафиг. лучше вообще без, чем с таким.
> Кстати, насколько я помню, kdbus - это не DBus, а довольно обобщённый
> механизм шиныесть мнение, что «обобщённый вариант шины» называется «сокет». по какому поводу не пойти бы господам улучшайзерам в задницу с их прибитым гвоздями к пингвинусу решением.
Это вы сейчас binder хотите с kdbus сравнить? Опять сравнили теплое с мягник
> Высокая производительностьТесты есть? Чтобы было понятно на сколько и в каких ситуациях.
А то бывает, что некоторые повыкидывают NOP'ы из своих программ, и начинают вопить про "высокую производительность", а потом выясняется, что производительность улучшилась-то на целых 0.0001%.
Переключения контекста - штука напряжная. Одна из причин по которой микроядра перманентно в ж...е.
L4 вполне себе так успешны
Историю успеха в студию
> Высокая производительностьПроизводительность в dbus вообще не нужна. dbus предназначен для обмена небольшими структурированными данными. Если надо скорость и объём, то для этого есть Unix domain socket. Впрочем, сейчас найдутся умники, которые будут гонять по нему фильмы и удивляться, что ой как оно тормозит. Однозначно надо в ядро пихать!
> Впрочем, сейчас найдутся умники, которые будут гонять по нему фильмыконечно будут. Где это видано - гонять управляющие потоки по одному IPC, а потоки данных - по другому, в рамках решения одной задачи?
Другое дело - если будет тормозить, то нужно ждать/писать новый, более гибкий в этом плане IPC.
Везде это видано. Например, стандартные пайпы типа cmd | cmd2 | cmd3. В сложных приложениях состоящих из нескольких процессов механизмы ещё больее разнообразны.
> конечно будут. Где это видано - гонять управляющие потоки по одному IPC,
> а потоки данных - по другому, в рамках решения одной задачи?везде, где данных много, а архитекторы вместо жопы внизу и жопы на шее имеют нормальное анатомическое строение.
>Например, некоторые разработчики нашли применение в kdbus даже для передачи звука в системе;
>Впрочем, сейчас найдутся умники, которые будут гонять по нему фильмы и удивляться, что ой как оно тормозит.Уже погоняли, похоже.
> dbus предназначен для обмена небольшими структурированными данными. Если надо скорость и объём, то для этого есть Unix domain socket.Звучит примерно так же грамотно, как и "HTTP предназначен для обмена небольшими структурированными данными. Если надо скорость и объём, то для этого есть UDP."
> HTTP предназначен для обмена небольшими структурированными данными
> ... Если надо скорость и объём, то для этого есть UDPтакое мог ляпнуть тольтко клинический идиот. Вообще HTTP действительно какое-то время не был приспособлен для передачи больших объёмов данных и для этого использовали другие протоколы вроде FTP с раздельными контрольным каналом и каналом передачи данных.
>> HTTP предназначен для обмена небольшими структурированными данными
>> ... Если надо скорость и объём, то для этого есть UDP
> такое мог ляпнуть тольтко клинический идиот. Вообще HTTP действительно какое-то время не
> был приспособлен для передачи больших объёмов данных и для этого использовали
> другие протоколы вроде FTP с раздельными контрольным каналом и каналом передачи
> данных.Кгхм. Вы что, считаете, что он сейчас приспособлен для передачи больших объёмов данных?
Это при том, что он не поддерживает, например, докачку? Я посмотрю на Вас, когда Вы будете скачивать LiveDVD по http, и на 95% у вашего провайдера случится обрыв канала. То-то радости будет всё заново качать.
> Это при том, что он не поддерживает, например, докачку?поддерживает. Тебе после разморозки разве ещё не сообщили?
С июня 1999 товарищ был в криогенном сне, сделайте ему скидку, не отошел еще.
> Это при том, что он не поддерживает, например, докачку?А про HTTP код 206 "partial content" - не, не слышали? У, хорошая у вас там криокамера.
>> Это при том, что он не поддерживает, например, докачку?
> А про HTTP код 206 "partial content" - не, не слышали? У,
> хорошая у вас там криокамера.Да. Я, пожалуй, и в самом деле в бункере зимовал. =)
Вот в результате таких верований всё имеет свои форматы обмена и, кроме велосипедизма и сопутствующих багов, нет универсального механизма мониторинга и модификации на лету.
> Вот в результате таких верований всё имеет свои форматы обмена и, кроме
> велосипедизма и сопутствующих багов, нет универсального механизма мониторинга и модификации
> на лету.а, да-да, я знаю. «у нас есть 14 стандартов, и мы придумали один универсальный…»
Ну скажи, какие есть плюсы у, скажем, сокетного IPC i3 перед шиной? А вот недостатки очевидны - автору пришлось наляпать велосипед по приему, отправке и базовому парсингу сообщений, и нет простого средства отмониторить в случае нужды, что за фигню ему туда шлют.
а всё почему? потому что дбас — говно. есть также мнение, что если говно засунуть в ядро, то не говно превратится в конфетку, а в ядре будет куча говна.
Вообще-то скорее потому, что там, где есть i3 (и, соответственно, нет DE) DBus вполне может и не быть.Да, а чем он тебя так раздражает? Я в реализацию не лез, но API там вполне вменяемые. ну разве что интерфейсов хотелось бы, как в COM - но это уже мои заморочки.
> Вообще-то скорее потому, что там, где есть i3 (и, соответственно, нет DE)
> DBus вполне может и не быть.…потому что оно говно и от него стараются избавиться.
> Да, а чем он тебя так раздражает?
про кривокод даже на лоре писали, это уже давно не смешно.
про то, что оно не текстовое — я писал, кажется. а если не писал, то сейчас пишу: оно не текстовое. собственно, всё: дальше мне уже неинтересно. то есть, мне было немного интересно, пока я на свою голову не почитал спеки формата. в общем, грустное оно. так никто не делит пышки.
не нужноа то этих системд-упорышей не остановить - навалят в ядро своего *овнокода
>не нужновозможно и не нужно
>а то этих системд-упорышей не остановить - навалят в ядро своего *овнокода
kdbus ваяет не САМ системд-поделкин, а "некто" Greg KH, так что очень велика вероятность, что г-нокода там не будет совсем.
если что я совсем не фанат поделки потера, но и не хэйтер, смотреть на это дело надо объективно, может быть в обозримом будующем таки будет толк от всей этой хрени.
> kdbus ваяет не САМ системд-поделкин, а "некто" Greg KH, так что очень велика вероятность, что г-нокода там не будет совсем.https://lkml.org/lkml/2014/4/2/420
в компании у Грега те еще г-нокодеры :) Так что еще как будет...
Ну тем более какие пробелмы - есть кому контролировать процесс.
> Ну тем более какие пробелмы - есть кому контролировать процесс.правильно. Есть - RedHat - как работодателю Лени и Грега. Вот и контролируют - что бы все попало.
Не потрудившись даже разработать как следует API. Главное свое запихнуть в ядро - другим будет сложнее и пофик что сырое суем - как с kpatch..
> правильно. Есть - RedHat - как работодателю Лени и Грега.Вообще-то KH насколько я помню из зюзи, так что FAIL - побиение редхата не состоится. Или придется сразу двух пинать. А вообще их таких много. Просто вы их не видите, потому что отморозились в вашем узком мирке где есть только вы и ваши потребности. А на планете более 6 миллиардов людей. И у них потребности иные. Вот они и делают то что надо им а не вам.
> А на планете более 6 миллиардов людей.Вас в каком году заморозили, уже более 7 млрд людей на планете земля. Так что с разморозкой.
> И у них потребности иные. Вот они и делают то что надо им а не вам.О да у 7 млрд иные потребности: пожрать, место где поспать и потрахатся. Им на kdbus вообе пофигу.
> Привилегированные пользователи могут подключить к потоку сообщений без создания специализированных механизмов в пространстве пользователячто подключить?
поток сообщений :)
раньше для этого вещества требовались, а теперь kdbus и вперед...
> что подключить?Нечто типа дебагера/трассира, позволяюшего оптом сгрести сообщения на шине и изучать кто, что, куда и почему. В случае ядра такую штуку проще сделать, потому что ядро - в нужном месте и в нужное время.
> апример, некоторые разработчики нашли применение в kdbus даже для передачи звука в системе;если можно систему заюзать каким-нибудь неестественным способом и всё сделать через задницу, то всегда найдётся олигофрен который это сделает и будет считать сие творение Ъ. Так что это скорее минус и упоминать о привлечении таких придурков на рекламируемую технологию лишний раз не стоит.
И не звука, а видео.
Что такого предоставляет этот kdbus, чего нельзя было реализовать с помощью сокетов? Пусть даже новым типом или протоколом, но в рамках системы сокетов?
> Что такого предоставляет этот kdbus, чего нельзя было реализовать с помощью сокетов?
> Пусть даже новым типом или протоколом, но в рамках системы сокетов?Вы неправильно задаёте вопрос. Шина как раз и нужна для того, чтобы избавиться от изобилия сокетов. Если у вас каждая программа общается с каждой, то у вас количество сокетов будет n!, а в случае системной шины - только n.
С другой стороны, действительно не понятно, зачем это в ядре.
> Если у вас каждая программа общается с каждой, то у вас количество сокетов будет n!,Вот же еврей безграмотный, не n!, а n(n 1)/2.
> а в случае системной шины - только n.
Типа замёл гогно под ковёр и сделал вид что не нагадил? Нет, такого в инженерии не бывает, полный mesh никак не масштабируется линейно даже с общей "системной шиной" не смотря на видимые N сокетов из юзерспейса. Внутри это всё равно будет ощутимо больше O(N) и по потреблению ресурсов и по локам/cpu.
Можно только снизить коэффициенты по памяти за счёт шаренной памяти при передачи больших объёмов данных, чего видимо и делает kdbus.
>> Если у вас каждая программа общается с каждой, то у вас количество сокетов будет n!,
> Вот же еврей безграмотный, не n!, а n(n 1)/2.Точно. Я зачем-то связи перемножил, вместо того, чтобы сложить. Да и взять сочетание из n по 2 было бы разумнее по смыслу. Спасибо. Я вчера был не в своей тарелке.
>> а в случае системной шины - только n.
> Типа замёл гогно под ковёр и сделал вид что не нагадил? Нет,
> такого в инженерии не бывает, полный mesh никак не масштабируется линейно
> даже с общей "системной шиной" не смотря на видимые N сокетов
> из юзерспейса. Внутри это всё равно будет ощутимо больше O(N) и
> по потреблению ресурсов и по локам/cpu.ну так про O(N) никто и не говорил. Но если уж сложность анализировать, то она очевидно будет как раз между n и n^2, что в любом случае какой-никакой, а плюс.
> Можно только снизить коэффициенты по памяти за счёт шаренной памяти при передачи
> больших объёмов данных, чего видимо и делает kdbus.А разумно ли передавать по шине большие объёмы данных? Мне казалось, что изначально цель была - пересылка большого количества маленьких управляющих конструкций. Запуск программ, пересылка событий и т.п.
> Если у вас каждая программа общается с
> каждой, то у вас количество сокетов будет n!, а в случае
> системной шины - только n.Стоп-стоп. Может проблема как раз в кривой архитектуре ПК, если у Вас каждая программа вынуждена общаться с каждой?
> Что такого предоставляет этот kdbus, чего нельзя было реализовать с помощью сокетов?Если заново сделать протокол с множесвенными отправителями и подписчиками ... получится как раз нечто типа dbus. А нафига его еще раз делать?
Например, можно точно знать, кто прислал сообщение
> Например, можно точно знать, кто прислал сообщениеа зачем? что тебе дадут pid'ы? а uid'ы? зачем они? дайте каждому юзеру по токену, если надо, и пусть ними авторизуются. я токен могу с собой носить какой хочу и куда хочу. даже между юзерами передавать, если мне вдруг так удобней показалось.
Если добавить сеть, то можно уже сравнивать с amqp :))
Вопрос в том почему бы туда сразу его и не впилить, вместо дбас.
Потому что это монстр, на фиг не нужный в рамках ПК и часто даже для проиводственных задач адски избыточный
Вот этого не надо. Еслу уж впиливать сеть - так совершенно тупо - дал адрес(а) - и туда летит всё, что можно, за исключением простейшего autodiscovery, как на свитчах делается. Без повторных отправок, гарантий доставки и подобной хрени. Надо будет - пусть это клиенты поверх реализуют. Сильно надо будет - нарастёт отдельная либа, которую эти клиенты будут юзать. Чай, не энтерпрайз какой.
То ли у меня с русским проблема, то ли у автора...."Kdbus может использоваться как в самодостаточном виде, например, данная система уже поддерживается в systemd"
Непонятно, причём тут "самодостаточность" и то, что модуль поддерживается посторонней прогой?? Самодостаточность - это значит программе не нужны внешние зависимости. Каким боком тут системД?
Ну оно для сустемд и задумано вообще-то... Такой вывод можно сделать рассматривая контингент просящих "dbus в вЯдро".
> "Kdbus может использоваться как в самодостаточном виде, например, данная система уже поддерживается в systemd"
> Непонятно, причём тут "самодостаточностьВсмысле как самодостаточный IPC без симуляции интерфейса D-Bus.
Пока эмулятор dbus через kdbus есть только у systemd.
Остальные подтянутся.
Кстати: на kdbus хотят переводить pulseaudio и gvfs :-)
gdbus будет тоже поддерживать kdbus.
> Кстати: на kdbus хотят переводить pulseaudio и gvfs :-)отличный список ненужно.
Кстати, gvfs - это, как по мне, даже больший урод, чем пульс. Вместо нормального автомонтирования с доступностью всему софту имеем частное решение. А потом оказывается, что в файл-менеджере файлик юзер видит, а в deadbeef его засунуть - никак. Видит око, да зуб неймёт.
> Кстати, gvfs - это, как по мне, даже больший урод, чем пульс.
> Вместо нормального автомонтирования с доступностью всему софту имеем частное решение.
> А потом оказывается, что в файл-менеджере файлик юзер видит, а в
> deadbeef его засунуть - никак. Видит око, да зуб неймёт.ну так DE-шки же. авторы DE-шек свято уверены, что есть только софт под их DE, который использует их библиотеки, и досадное недоразумение в виде ядра, которое лучше бы тоже переписать на их библиотеках.
в итоге одни сочиняют KIO, другие gvfs, а вместе всё это как было кучей хлама, так и остаётся.
> авторы DE-шек свято уверены, что есть только софт под их DE, который использует их библиотеки, и досадное недоразумение в виде ядра, которое лучше бы тоже переписать на их библиотеках.:-D