Грег Кроа-Хартман (Greg Kroah-Hartman) представил (https://lkml.org/lkml/2014/11/21/3) для включения в ядро Linux второй вариант патчей с реализацией kdbus, надёжной, быстрой и безопасной системы обмена сообщениями, поддерживающей доставку сообщений как в мультикаст-режиме (от одного отправителя к группе получателей), так и в режиме точка-точка. Kdbus может использоваться как обособленно, например, данная система уже поддерживается в systemd, так для создания реализации D-Bus, не требующей запуска отдельного демона в пространстве пользователя.
Вторая версия патчей примечательна значительной переработкой кода и некоторыми существенными изменениями в реализации. Например, в качестве интерфейса для обращения к kdbus вместо устройства /dev/kdbus предложена новая псевдофайловая система kdbusfs, по умолчанию монтируемая как /sys/fs/kdbus. Кроме того, в новом выпуске изменена логика прикрепления метаданных, обеспечена привязка пространств имён, добавлены новый объект kdbus_node и флаг _KDBUS_ATTACH_ANY, проведены оптимизации производительности.
Из основных достоинство реализации шины kdbus на уровне ядра отмечается:
- Высокая производительность за счёт минимизации переключения контекста процессов, меньшего выполнения операций копирования, сокращения системных вызовов, использования memfd;
- Высокая безопасность из-за исключения влияния пользовательских процессов на содержимое шины и использования механизмов ядра для управления передачей данных, в том числе с возможностью контроля со стороны модулей LSM;
- К сообщениям может быть прикреплено больше метаданных;
- Пригодность для приложений, обрабатывающих большие потоки данных, с возможностью расстановки сообщений в очереди на основании приоритетов и задания глобального упорядочивания сообщений. Например, некоторые разработчики нашли применение в kdbus даже для передачи звука в системе;
- Неподверженность многим состояниям гонки, которые трудно устранить в реализации на уровне пользователя. Например, ситуация отсоединения клиента от шины только при условии отсутствия сообщений в его очереди;
- Возможность мониторинга на уровне ядра. Привилегированные пользователи могут подключить к потоку сообщений без создания специализированных механизмов в пространстве пользователя;- Возможность прямой доставки сообщения без помещения в очередь, что удобно при организации обработки запросов активации по шине;
- Возможность раннего доступа к шине, на этапе выполнения initrd.
URL: https://lkml.org/lkml/2014/11/21/3
Новость: http://www.opennet.ru/opennews/art.shtml?num=41106
> "<...> некоторые разработчики нашли применение в kdbus
> даже для передачи звука в системе; <...>"Какая-же всё-таки пропускная способность у kdbus. А то может и видео гонять, и прочие вещи можно было бы.
Способность-способностью... Ну не нужен звук и видео. Почти нигде не нужен. Особенно умиляют (от слова "ненависть") ребята, рассказывающие о чём-то новом (или старом в научно-популярном стиле) в виде видео. Я желаю им стать сексуальными раба Ктулху когда он проснётся и оставаться ими пока он их не съест.
Одним нужен другим не нужен, тут даже не конкретно в видео дело, а в том, хватит ли пропускной способности (без 100% загрузки проца на её обеспечение, конечно) на перекачку произвольных данных на скоростях, того же порядка, что нужны, например, для видео.
> без 100% загрузки проца на её обеспечение, конечнодумаешь, придурков данное ограничение будет волновать? Ох какой наивный
меня почему-то мало интересует, что волнует придурков, а что нет. Пусть в оффтопике об этом заботятся.
Придурки являются частью свободного сообщества. Так что с некоторыми их выкрутасами придётся сталкиваться так или иначе...
> сталкиваться так или иначе...При том универсальный критерий придурошности еще не изобрели. Что одному хорошо, другому может быть неудобно, например. Люди бывают разные.
Странно. А я думал психиатрия уже научилась различать лёньчиков и нормальных людей.
> Странно. А я думал психиатрия уже научилась различать лёньчиков и нормальных людей.так идеи-то у них зачастую вовсе не сумасбродные. иногда даже вполне разумные и интересные. вся беда потом начинается.
> вся беда потом начинается.Да, когда некто приходит и смеет назвать вещи своими именами. Заявив что бабушкин хлам в сундуке уже сгнил и поэтому половину надо отнести на помойку. В этом месте у "бабушек" случается истерика.
>> вся беда потом начинается.
> Да, когда некто приходит и смеет назвать вещи своими именами. Заявив что
> бабушкин хлам в сундуке уже сгнил и поэтому половину надо отнести
> на помойку. В этом месте у "бабушек" случается истерика.не в этом, а в том, когда он предлагает заместо «хлама» (про который он даже не знает ничего) попросту насрать в сундук.
> который он даже не знает ничего) попросту насpать в сундук.Это как раз бабушкино восприятие - мол как это, выбросить сгнившее и сложить что-то еще? Ааа, в сундук "наcpaли"!!!111. А по факту это на грани старческого маразма.
>> который он даже не знает ничего) попросту насpать в сундук.
> Это как раз бабушкино восприятие - мол как это, выбросить сгнившее и
> сложить что-то еще? Ааа, в сундук "наcpaли"!!!111. А по факту это
> на грани старческого маразма.нет, по факту это в сундук насрали.
>Какая-же всё-таки пропускная способность у kdbus. А то может и видео гонять, и прочие вещи можно было бы.Я что-то не понимаю. Сокеты из линукса уже выпилили? А то уж очень странно наблюдать, как некоторые страдают от невозможности гонять видео с помощью технологии, совершенно для этого не предназначенной.
> Я что-то не понимаю. Сокеты из линукса уже выпилили? А то уж
> очень странно наблюдать, как некоторые страдают от невозможности гонять видео с
> помощью технологии, совершенно для этого не предназначенной.Что-то я не видел *NOT FOR VIDEO* тега у kdbus. И вообще откуда берутся такие представления, что механизмы ядра включают в себя ещё и политики по их использованию (не для видео, например)?
Есть характеристики у протокола, например, пропускная способность, задержка, накладные расходы. Подходят под задачу - применяй, не подходят - ищи другой. Поэтому именно характеристики и представляют интерес.
> Что-то я не видел *NOT FOR VIDEO* тега у kdbus.Это определяется элементарным здравым смыслом. Если у тебя летает чуть ли не гиг в секунду (поток данных на экран без сжатия нынче перевалил за несколько гигабит) - с ним надо делать как можно меньше. Ибо любая самая копеечная операция на нем станет очень даже заметной по нагрузке на проц и память.
Поэтому тега - нет. Но здравый смысл подсказывает что гонять видео по шине может быть достаточно накладно. А тэги расставляют только для тех кто совсем лыко не вяжет, ну как микрософт запрещает хранить бинарники типа файлов в реестре. При том, технически это как бы можно, а практически - ни к чему хорошему не приведет. Хотелось бы чтобы линуксные разработчики не нуждались в пояснениях на ТАКОМ уровне.
Обычно для больших объемов используется шареная память, а не сокеты.
> Например, некоторые разработчики нашли применение в kdbus даже для передачи звука в системе;И мы все знаем что это за разработчики такие.
Таки встроят ПульшшшАудио в шишшштем-дэ?
Не понимаете вы Путь Великого Поттера. Надо не встраивать пульс в системду, а делать для системд новый костыль audiod.
> некоторые разработчики нашли применение в kdbus даже для передачи звука в системетеперь профнепригодные инженеры будут не только пустой вебдванольной страничкой душить браузером юзерспейс, но и всё ядро какими-нибудь простым гномовским апплетом.
Ну хоть на этот раз хватит у Линуса ума запечатать эту шайку смачным факом или и дальше будет яйца мять и наговаривать что пока ничего плохого с его детищем не происходит.
как будто до kdbus-а было душить систему апплетам нельзя, а тут вдруг станет возможно. Не нравится апплет - не используй, в чём проблема?
да, нельзя т.к. были они местячковыми и от них можно было отказаться. Теперь это будут прибиывать гвоздями и подавать такой шит как "best practice". Дальше дерьмо растечётся везде через профнепригодных разработчиков без собственного чувства инженерной адекватности.
шайка ему за смачные факи кислород в баллоне перекроет через тот дбас, когда он будет в следующий раз отмывать свои тридцать серебреников полученные от микрософта через редхет.
> шайка ему за смачные факи кислород в баллоне перекроетТорвальдс для начала ничего против системды не имеет. Ему не нравится изишний шум и некоторые закидоны разработчиков, но это не имеет ничего общего с хейтерством системды, да и строить он кого угодно умеет.
сколько про него пишут, но так и не понятно зачем пихать юзерспейс в ядро. следующим шагом будет перенос kdbus в юзерспейс, как когда-то сделали с fuse.
Не тупи. Если какая-то технология родилась в юзерспейсе, это еще не значит что ее место априори только там. Ты еще спроси по той же логике зачем в файломанагеры переносят функции копирования из ядра. Подумаешь, прогрессбары - они для неженок.Короче говоря, в последнее время количество школоты, образовашейся в собществе и не могущей связанно мыслить, ничего кроме печали не приносит.
Школота школотой, а некоторые (я , например) хоть и в шаге от 25 , использую линукс только ,как тут многие(язвительно) говорят, "админ локалхоста", но с радостью бы читал внятные комментарии о том, почему лучше так , а не этак. Или коменты, которые разъясняли что-то непонятное из прочитанного. А на данный момент можно узнать лишь то, что Поттеринг-редиска, оффтопик-говно, школьники должны идти в школу. Обидно , господа..
Вот например одни из заказчиков "dbus в ядре": http://projects.genivi.org/
Очень хочется им гонять видео и звук через IPC.
а) кто это вообще?
б) чем их не устроили сокеты?
Ну а как ты себе представляешь корректный ответ на вопрос вида "нахрен оно вообще нужно, разработчики ядра тупые что ли"? О том и речь, неадекватов много, связно на технический вопрос теперь ответить может хорошо если 1 из 20.
Не стоит расчитывать на то, что остальные присутствующие знают больше вас, если интересно лучше самому найти и почитать.Однако, суть проблемы изначально в том, что все механизмы обеспечивают взаимодействие 2х процессов, нет ну можно там через разделяемую память, но все это не типовое использование сильно смердящее костылями.
Уже очень давно нужен софтроутер, некий механизм обеспечивающий взаимодействие многих процессов, однако универсальный, он многих не устраивает, т.к. заточенный под конкретную задачу может сильно поднять производительность одним и уронить другим,а если очевидного пути нет, как нет и сильного лидера способного пнуть сомневающихся, общество уподобляется стаду и бесцельно топчется на месте,доказывая преимущества "своего" пути.
Конечно есть реализации - дбас, как одна из многих, но все они, большенство, выползли из других проектов и сильно под них заточены. Реализация на уровне ядра как попытка унифицировать интерфейс. Однако пока довольно мутно, разработчики как будто сами не знают чего хотят, ну каждый конкретно может быть, а вцелом нет.
Что лично на мой взгляд довольно глупо, потому что, если со временем обеспечить взаимодействие между компонентами ядра между собой через эту подсистему, а также между ядрами ОСей различных систем,то можно получить вкусный пирожок, ввиде распределенной на уровне ядра системы,докрутить резервирование аля дублирование процессов и скайнет готов, и хрен его отключишь)), а дальше роботов проблемы)
А вообще удивлен, что прикрутить псевдо фс только сейчас додумались, с нее надо было начинать, и вообще делать это основным интерфейсом.
> следующим шагом будет перенос kdbus в юзерспейс, как
> когда-то сделали с fuse.Тут ровно наоборот - dbus появился в юзерспейсе, но простой подвид - внесли в ядро.
Аналогично, файловые системы в FUSE пригодны только для применений где нет больших потоков данных. А например обычная запись на НТФСный диск адово грузит проц, во многие разы превосходя нагрузку на проц от обычных ФС. А порой тормоза настолько сильные что скорость записи на диск упирается в проц, а не собственно диск.
dbus kdbus звук systemd значительная переработка кода, спец файловая система -- В ЯДРО - происки сотоны
> dbus kdbus звук systemd значительная переработка кода, спец файловая система
> -- В ЯДРО - происки сотоныВсе проще. Вот например, хочешь ты допустим синтез речи. Есть штук пять софтварных синтезаторов, а еще куча железяк которые умеют это хардварно и прочая. Есть особенности системы, типа десятка устройств вывода звука. А теперь представь что ты хочешь чтобы твоя программа просто матюкнулась голосом по какому-нибудь поводу. Что, не очень просто получается? Да, было бы проще пульнуть по шине "эй там, кто-нибудь, озвучьте вот это!". И все.
На словах звучит красиво и прельстиво. Надеюсь, тут не повторится часть истории другого, весьма знаменитого, продукта.
> вместо устройства /dev/kdbus предложена новая псевдофайловая система kdbusfs, по умолчанию монтируемая как /sys/fs/kdbusСупер. Теперь и эта поделка, которая могла бы потенциально быть реализуемой на разных системах, гвоздями прибита к линуксу.
Удивительно, что разработчики ядра Линукса пишут исключительно под Линукс?
Судя по наблюдаемому исключительно под определённые версии линукс.
Если вы хотите запустить нашу программу версии х.хх ставьте линукс ядра версии с а.а.2 до а.а.15. Кроме ядра а.а.10 - там неправильно отрабатывала фс. Если хотите использовать нашу прогу версии у.уу ставьте ядро линукс версии с а.б.1 до а.с.3
Обычно все это волнует только какие-то сильно системные программы, типа либ DRM, например. И там обычно есть fallback для старого кода, хоть и означающий более тормозную работу, разумеется.
Зема, ты видел ентерпрайз? Там проги на яве таскают с собой старую баговую яву. А на новой не работают. И внутри куча кода прилинкованного к какому-нибудь свободному коду. И этот свободный код везде дублируется. Так что я верю в программеров новой волны.
> Так что я верю в программеров новой волны.это в большинстве случаев не «программеры новой волны», а менеджмент старой. в стиле: «да поехали, потом заведёшь!» набирают идиотов пучок за пятачок, те что-то как-то пишут. иногда даже не идиотов набирают, но: «мы назначили дедлайн на позавчера, поэтому нас ничего не волнует, завтра взлетаем.»
натурально, при помощи матюгов и чёрной магии с человеческими жертвоприношениями всё это как-то таки начинает ковылять. после чего манагеры радостно рапортуют, что «ещё один успешный продукт вышел в продакшэн, ура!» после чего «успешный продукт» тем более никто не будет приводить в порядок, потому что это стоит денег (зачастую столько, что проще выкинуть и новый сделать), а видимого толка никакого: ведь работает же!
а если что, то опять же не манагерам отвечать, они-то продукт сдали. и на повышение уже ушли, возможно.
p.s. нет, программеров тоже нельзя самих оставлять. в том, собственно, и состоит задача хорошего менеджера, чтобы с одной стороны не давать программерам заигрываться в бирюльки, а с другой не загонять лошадей, пытаясь потом выдать их гуано за продукт.
> Супер. Теперь и эта поделка, которая могла бы потенциально быть реализуемой на
> разных системах, гвоздями прибита к линуксу.Да вообще охренеть - ядро линукса работает под линуксом :).
Зачем и кому это нужно, а так же насколько оно будет полезно - пока не до конца понятно.
DBUS как бэ устарел и разрабы хотят больше (больше!!) фич, оно понятно.
Вопрос почему вездесущий лёнька потхэд это не запилил в своей поделке.
Хотя вполне может быть что именно лёньке оно нужно в ядре.
Х3надеюсь, что дядюшка Грег сделает _это_ по человечески.
Вроде он Леннарт запили что-то похожее
>DBUS как бэ устарелПосмеялся.
>>DBUS как бэ устарелОн с самого начала был куском г-на. https://www.linux.org.ru/forum/development/7881682
> Зачем и кому это нужно, а так же насколько оно будет полезно
> - пока не до конца понятно.Вроде ж известная история про dbus в ядро, разве нет? Леннарту и КО нужен dbus, а kdbus -- это dbus, только намного лучше (см. новость + [1]).
[1] http://lwn.net/Articles/580194/
> DBUS как бэ устарел
С одной стороны, IMHO, dbus изначально был не нужен (и не нужен до сих пор). С другой -- я совершенно не вижу с чего это вдруг он устарел. Не могли бы пояснить?
> Вопрос почему вездесущий лёнька потхэд это не запилил в своей поделке.Что вы тут имеете в виду?
> С одной стороны, IMHO, dbus изначально был не нужен (и не нужен
> до сих пор).А как по мне так логично если прогрмама может кинуть сообщение заранее неопределенной группе подписчиков, ничего о них толком не зная.
Грубо говоря, если это ноут и юзер попросил самолетный режим - будет логично если юзеринтерфейс через который юзер это сделал, пульнет в шину сообщение вида "у нас тут самолет - а ну все радиопередатчики, заткнитесь и не излучайте!". При этом не так уж важно какой именно был интерфейс и об этом никому из программ знать не надо. Будь ли это обработчик хардварных кнопок "выключения сети", менюшка в гуе или какой-нить командлайн - их програмерам было бы удобнее реализовать пуляние 1 сообщения в шину чем греть мозг вопрсами устройства системы, ее сети, кто сетью пользовался и прочее.
С другой стороны - все причастные к излучениям смогут зашатдаунить свои девайсы. А софт использовавший сеть при наличии заинтересованности сможет сделать вывод "сейчас у нас отнимут сеть" и среагировать адекватно. При том весь этот софт о друг друге ничего может и не знать. Торрент может аккуратно запаузить закачки, мессенжер - свалить в режим ожидания, ну и так далее. А потом их можно проанонсировать что эмбарго на сеть снято - мол, качайте наздоровье.
А если рассуждать о нужности в таком духе - компьютер не является абсолютно необходимым для жизни, да и без электричества можно перекантоваться.
>по человечески.напишет феминистское воззвание вместо кода?
Отлично, чем скорей его смерджат - тем лучше.
Ну если systemD фигурирует в контексте такой новости, значит жить эта система будет долго жить.
Тортик!! Жду момента, когда можно будет пересобрать systemd с флагом kdbus.
чем kdbus лучше netlink кроме использования xml ?
plist удобнее xml, я бы поспорил насчет лучше.
> чем kdbus лучше netlinkПримерно тем же чем отсылка сообщения на опеннет по HTTP лучше выкройки кастомного протокола с самоличным формированием всего содержимого фреймов эзернета, с самоличной разбивкой на фреймы и прочее, по кастомному протоколу. А соседний сайт придумает свой протокол. В пять раз лучше. Но другой. А третий сайт... ну вы поняли :).
да да, и когда нам надо переслать бинарные данные - создаем html с uuencode, и вперед. а вдруг бинарные данные не так прочитаются.
Прикольно. Kdbus может стать неким подобием ipc в микроядрах, если он достаточно быстр. Неужели это даст возможность прикрутить к ведру микросерверы, постепенно убирая модули?
а что netlink это не позволяет ?
Да. Уже давно позволял.
Вообще ситуация похожа на очередные внутриядерные разборки. Будет больше сущностей.
> Да. Уже давно позволял.
> Вообще ситуация похожа на очередные внутриядерные разборки. Будет больше сущностей.ситуация напоминает - "у меня тут есть свое, а что там до меня сделали - мне не важно, ну сломается и черт с ним". Прям как пропихивали pulseaudio и сломали alsa/osd. что портер тогда ответил? что его не интересует как работает всякие там alsa/osd - его интересует только pulseaudio.
Не то, чтобы сломали алсу, ведь пульса тоже через неё звук выводит. Да и остались ещё приложения, выводящие звук через OSS. В таком разброде только врапперы спасут мир, вот только пульса, тоже являясь враппером, ничего полезного не делает.
> ничего полезного не делает.Кроме регулировок громкости по приложениям и способности нормально справляться с черти-каким месивом софта и девайсов - см. например как в N900 сделано - там звук может идти на ушной динамик, на боковые спикеры(они же звонок), на наушник, на чего-нибудь по блутусному интерфейсу, etc, etc. И если например входящий звонок - очень удобно если плеер при этом заткнется. И нет, с одной алсой такие маневры не больно результативно получаются.
Поменяли инструменты, ибо кроме mix/snoop для алсы есть всё, даже прослойки для vst-плагинов. Но по крайней мере, в вашем сценарии можно, используя статические маршруты вместо переключения, даже фэйд сделать. Просто в наше время пульсопропаганды стали забывать о плагинах алсы.
> маршруты вместо переключения, даже фэйд сделать. Просто в наше время пульсопропаганды
> стали забывать о плагинах алсы.А пульс работает и мозг особенно не греет. А то что им нокия взялась разруливать довольно требовательную и ответственную задачу - как бы намекает, что не так страшен черт как хейтеры его малюют.
> А пульс работает и мозг особенно не греет. А то что им
> нокия взялась разруливать довольно требовательную и ответственную задачу - как бы
> намекает, что не так страшен черт как хейтеры его малюют.ага. например, на то, что mplayer, пересобраный без идиотской пульсы и с убитым пульсодемоном, фильмы может играть на час дольше.
или то, что у пульсы, конечно, есть протокол для передачи звука по сети, но сделан как и всё остальное: категорически ломается с новыми версиями. обновить пульсу тоже нельзя, потому что API… см. протокол, тогда софт ломается. в итоге чудная возможность гнать по сетке звук… ну да, работает, как и всё остальное в пульсе.
а уж о том, что оно не способно даже нормально выставить уровень громкости при переключении, и надо дополнительно пинать, чтобы вспомнило, и упоминать как-то неудобно.
а в остальном, прекрасная маркиза, всё хорошо, всё хорошо.
> убитым пульсодемоном, фильмы может играть на час дольше.Это круто, конечно, но при этом у аппарата отваливается столько других функций что радость от этого мне например крайне сомнительна. Все-таки с таким экраном смотрение фильмов на нем - явно не основной приоритет.
> или то, что у пульсы, конечно, есть протокол для передачи звука по
> сети, но сделан как и всё остальное:Вот это мне честно говоря совсем пофиг - я этим просто не пользуюсь и вроде бы и не планирую.
> версиями. обновить пульсу тоже нельзя, потому что API… см. протокол,
Зато у MSDOS апи не обновляется - пользуйтесь наздоровье. Вон эмулируйте какой-нибудь саундбластер на порту 220h и вперед. Правда что такое порт 220h на ARM - я не знаю, но любителей стабильности апи такая фигня смущать не должна - они привычно расскажут что ARM это от лукавого - надо на спине таскать системник IBM PC AT, с настоящей ISA. Не то что эти ваши суррогаты на LPC bus :).
> да, работает, как и всё остальное в пульсе.
Ну мне это жить не мешает - у меня нет бзиков по тотальной сетевой прозрачности всего и вся и при том почему-то обязательно через пульс. Возвращаясь к твоему примеру с шиной, декомпресснутое видео в fullhd и выше как-то не очень пролезет без потерь кадров даже по гигабиту.
> громкости при переключении, и надо дополнительно пинать, чтобы вспомнило,
Переключении кого и куда?
> а в остальном, прекрасная маркиза, всё хорошо, всё хорошо.
Да как-то так на самом деле про любой софт сказать можно :).
> Переключении кого и куда?спикер<->уши, при звонке, например. ай. извини, хазяина, нимагу, скилирос.
Если я правильно понял, то netlink использует сокеты и соответственно создаёт больший оверхед. (на истину в последней инстанции не претендую, всего лишь догадка)
а тут создают файловый дискриптор. overhead не меньший. при этом netlink работает - а это еще надо допиливать и тестировать.
> - а это еще надо допиливать и тестировать.А нетлинк как таковой не особо то и интерфейс IPC. И достаточно простой. Он как-то не тянет на альтернативу d-bus c такими свойствами. Используется несколькими программами для низкоуровневой работы с ядром. И вроде как все.
Самое интересное, вроде у геноды получилось. Они заявляют, что микромодули благодаря zerocopy работают так же быстро, как и ядерные.
А практически мне понравился GNU/Hurd. Всё аккуратно. Settrans управляет микросерверами. А Похороникс постил графики небольшого отставания в производительности от Дебиана.
> работают так же быстро, как и ядерные.Это уже который раз заявляют? :). А так у kdbus не полный zerocopy. Если сообщение менее 512К, его таки копируют, ибо затраты на установку маппинга перевешивают затраты на копирование. А более крупные блоки - уже да, просто маппят.
> А практически мне понравился GNU/Hurd. Всё аккуратно. Settrans управляет микросерверами.
> А Похороникс постил графики небольшого отставания в производительности от Дебиана.Мне все это малоинтересно - я не вижу что я от всего этого выиграю, но вижу уйму новых потенциальных проблем.
Самая частая проблема дров - отвал железки и рассинхрон состояния железки с тем что ожидает драйвер. Левые доступы к памяти - ну, наверное, это бывает. Но сбои дров которые я видел - были в основном по части того что железка и драйвер в своих заскоках разошлись во мнениях и далее драйвер не смог выправить глюки железки, так что все вошло в штопор. В таком случае железка может остаться неработоспособной до жесткого ребута, а то и poweroff. Я не вижу как тут поможет микроядро, а улучшение надежности на еще капельку при том что меня и так нестабильность не донимала, а просадки производительности и отсутствие дровопсак потом могут сильно испортить жизню - хз, я уже слышу сказки про микроядра пару десятков лет, но воз и ныне там. Да, был QNX Demo Disk. Да, стартовал с 1 флопа. Но по факту распаковывался в 6 с гаком, там было пару программ и минимум драйверов. И в резульате ни диски подцепить, ни железо толком не работало. С тех пор прошло более десятка лет, а принципиально мало что изменилось. Все те же крутые концепты все так же малопригодные для каких-то практических задач, под бойкие рассказы очередных разработчиков что уж эта модель вечного двигателя точно всем покажет как из вакуума энергию генерить. А все практически значимые ОС общего применения как-то так вышли гибридами или модульными монолитами, у обоих одно ядерное пространство и разница довольно номинальная.
Надёжности много не бывает. Помню, в далёком 2007 году у меня был СДМА модем, который при определённых дисконнектах останавливал ведро. До паники даже не доходило. Баг починили быстро, но всё-таки концепция микроведра приходит на ум. Есть ещё критичные сервера, которые нельзя останавливать, даже не смотря на отвалившиеся диски (не корневые, конечно). Тут нужно поднять новый, оставив старый работать дальше, правда с повсеместной виртуализацией такое встречается всё реже.
>> - а это еще надо допиливать и тестировать.
> А нетлинк как таковой не особо то и интерфейс IPC. И достаточно
> простой. Он как-то не тянет на альтернативу d-bus c такими свойствами.
> Используется несколькими программами для низкоуровневой работы с ядром. И вроде как
> все.вполне позволяет использовать между программами, а не только ядро<>прикладуха.
нет. Hurd/Mach который вы описываете - из Линукса так не сделать :)
и по перформансу оно тоже - не вполне. к сожалению. но отклик довести до разумного уровня - наверное можно(пишут по кр. мере, что шанс есть).
Говорят, что не всё так плохо
http://www.phoronix.com/scan.php?page=article&item=debian_gn...
Статья, конечно старьё...
> предложена новая псевдофайловая система kdbusfs, по умолчанию монтируемая как /sys/fs/kdbus.Интересно.
Означает ли это, что посылать сообщения можно командой вида echo "..." > /sys/fs/kdbus/... ?
Нет. Там сообщение через ioctl идут вроде. Можно будет через busctl (часть systemd). Ну или что-то другое. Я думаю, что systemd-хейтеры осилят userspace утилиты для kdbus.
> Нет. Там сообщение через ioctl идут вроде.то есть, единственное, что можно было бы засчитать преимуществом — и то не сделали? молодцы.
> то есть, единственное, что можно было бы засчитать преимуществом — и то
> не сделали? молодцы.Скрипты не должны делать низкоуровневые вещи напрямую - их дело быть glue кодом между соотв. утилитами - они всегда для этого и служили.
я рад, что ты в курсе. только речь была совсем не о том.
> я рад, что ты в курсе. только речь была совсем не о том.Могу предположить что тебе какие-нибудь ioctl'ы не нравятся и т.п., наподобие того как с tun/tap?
>> я рад, что ты в курсе. только речь была совсем не о том.
> Могу предположить что тебе какие-нибудь ioctl'ы не нравятся и т.п., наподобие того
> как с tun/tap?все, собственно. потому что я не понимаю, зачем мне в шине сообщений ioctl-и, и почему я не могу просто плюнуть текст в файл и прочитать текст из файла.
для тех, кто любит в ластах и гамаке, а потому всенепременно хочет гонять по шине сообщений lossless audio и hd-video, пусть будут ioctl (хотя лучше таких сразу отправлять улицы чистить). для большинства применений шины сообщений это не надо, программы обмениваются небольшими «приветами», и никакой разумной причины не давать посылать эти приветы при помощи echo или cat, равно как и смотреть при помощи каких-нибудь sed, grep и awk я не вижу.
> ioctl-и, и почему я не могу просто плюнуть текст в файл
> и прочитать текст из файла.В результате с tun/tap все пришло к тому что скрипты дергают соотв. утилиты. А кто хочет сильно глубоко лезть в системную механику - юзает си и дергает соотв. вызовы. Что логично. Все это работает и никаких особых проблем с этим нет. А пытаться представить все как текст ... стоп, а почему по шине может летать только текст? А например аудио послать - что, натурально, возбраняется? Ну или как ты его в виде текста представить собираешься?
> гонять по шине сообщений lossless audio и hd-video, пусть будут ioctl
> (хотя лучше таких сразу отправлять улицы чистить).А я вижу некоторые валидные сценарии. Например распознавание и синтез речи. Так чтобы программам не надо было знать интимные особенности движков и который из них вообще в вон той системе, а движкам ни к чему знать что это за программа и где она эти данные берет. Плюнул сообщение - получил результат. Вроде логично. Ессно до определенного предела - декомпресснутое видео в HD таким манером забуксует даже на ядерной реализации, вероятно.
> для большинства применений шины сообщений это не надо,
Понятия о большинстве у разных людей разное. Большинство людей могут быть совсем не против голосовых интерфейсов с компьютером например. И будет неплохо если шина к этому будет готова.
> разумной причины не давать посылать эти приветы при помощи echo или
> cat, равно как и смотреть при помощи каких-нибудь sed, grep и
> awk я не вижу.Попробуй сделать grep на сэмплах с микрофона. Не забудь рассказать как получилось. Нет, это не аудиоредактор. А всего лишь какое-нибудь голосовое управление.
> В результате с tun/tap все пришло к тому что скрипты дергают соотв.
> утилиты.только я вижу некоторую разницу между tun/tap и шиной сообщений? и не только в названии, но и в предназначении и в частоте использования?
> А например аудио послать - что, натурально, возбраняется?
не возбраняется. но лучше это дело максимально затруднить, чтобы у идиотов больше сил уходило на их идиотизм.
> Ну или как ты его в виде текста представить собираешься?
я его не собираюсь в шину сообщений кидать.
> А я вижу некоторые валидные сценарии. Например распознавание и синтез речи. Так
> чтобы программам не надо было знать интимные особенности движков и который
> из них вообще в вон той системе, а движкам ни к
> чему знать что это за программа и где она эти данные
> берет. Плюнул сообщение - получил результат. Вроде логично.только если очень сильно упороться. а если не упарываться, то waveform следует класть в какой-нибудь /tmp, и передавать имя файла по этому поводу. причём это может быть не только блочный файл, но и труба какая-нибудь, например. а вот гонять это полностью в сыром виде через ядерную шину сообщений — лично в моём мире называется непечатными словами.
> Ессно до определенного
> предела - декомпресснутое видео в HD таким манером забуксует даже на
> ядерной реализации, вероятно.ну зачем же такие драконовские ограничения? что, голос, значит, нормально, а если я видео хочу проиграть — то всё, уже никак? нет, я тогда и про видео думать не хочу, пусть и видео через системную шину летает! сначала кодированое, а потом по дороге декодер его ловит и дальше уже в raw-виде выплёвывает. кому-нибудь ещё. отличное же решение!
>> для большинства применений шины сообщений это не надо,
> Понятия о большинстве у разных людей разное. Большинство людей могут быть совсем
> не против голосовых интерфейсов с компьютером например. И будет неплохо если
> шина к этому будет готова.не, без raw-видео в разрешении 100500x100500 никак. давайте всё в шину пихать. кстати, операции с файлами тоже не нужны, это всё тоже через шину. и сеть туда же.
только вот это совсем так чуть-чуть другая система получается. с совсем другими принципами и архитектурой. не надо пихать невпихуемое.
>> разумной причины не давать посылать эти приветы при помощи echo или
>> cat, равно как и смотреть при помощи каких-нибудь sed, grep и
>> awk я не вижу.
> Попробуй сделать grep на сэмплах с микрофона. Не забудь рассказать как получилось.
> Нет, это не аудиоредактор. А всего лишь какое-нибудь голосовое управление.нет, это не «голосовое управление», это говнософт, который сносится сразу по обнаружении того, что он пытается пихать в шину подобный мусор.
кстати, я так понимаю, что посылки ты тоже исключительно письмами хочешь слать? а чего, ведь почта же, пусть жуёт. какая разница — письмо ли, посылка «хрупкое» или вагон кирпичей… всё надо одним и тем же транспортом!
> не возбраняется. но лучше это дело максимально затруднить, чтобы у идиотов больше
> сил уходило на их идиотизм.Обсуждалось год назад. Люди очень, очень хочут гонять видео. В рассказы про то, что топология кольцевой шины принципиально не позволяет держать нагрузку близкую к критической для компа, не верят.
ага. люди завсехда хочуть странного и глупого. к сожалению, так же часто путают одно с другим.
> ага. люди завсехда хочуть странного и глупого. к сожалению, так же часто
> путают одно с другим.ЧСХ у них это порой получается. Вчера все удивлялись зачем надо много ядер на десктопе, а сегодня и на смарте 8 ядрами никого не удивишь.
> ЧСХ у них это порой получается. Вчера все удивлялись зачем надо много
> ядер на десктопе, а сегодня и на смарте 8 ядрами никого
> не удивишь.что, кстати, характерно — так никто и не знает, зачем же оно надо. при том, что софт становится всё больше и всё тормознее, убеждение в том, что хотели глупого и получили глупого не просто крепнет, а не имеет альтернативы.
Ну знать-то знает - для игр и чтобы когда ВНЕЗАПНО появляется сеть и все 100500+ клиентов социальных, асоциальных и постсоциальных сетей и столько же мессенджеров и прочих приложений "кааак ломанулись" качать да парсить да перелопачивать страннейшими и эффективнейшими образами всё, произошедшее в этом печальнейшем из виртуальных миров за время отсутствия в нём абонента, всё это происходило как-то побыстрей.Другой вопрос - что старый ибээмовский лозунг "машина должна работать, а человек - думать" - он, конечно, всё более актуален с точностью до наоборот и сдерживается его стремительная поступь исключительно отсутствием больших прогрессов в научении машины не то чтобы даже думать, но хотя бы отслеживать контекст. Но то что идеальная среда обитания, мечту о которой лелеют широкие народные массы прогрессивного человечества представляет собой чистенький коровник - это как бы не новость.
Идеальное мобильное приложение должно проанализировав контекст (оценив обстановку, уставно выражаясь), принять решение (среднего качества, AI нинужна, достаточно поискать по паттерну в базе) и послать сигнал, желательно прямо в мозг (и на этом поприще уже достигнуто прогрессов, академику Павлову и не снилось), чтобы человеку будущего оставалось лишь выполнять простые однозначные команды, в идеале - не просыпаясь вообще.
> Вчера все удивлялись зачем надо много ядер на десктопе, а сегодня и на смарте 8 ядрами никого не удивишь.Все и сегодня знаю что столько ядер на смарте не нужно. И все знают что такое маркетинговый булшит.
> ЧСХ у них это порой получается. Вчера все удивлялись зачем надо много
> ядер на десктопе, а сегодня и на смарте 8 ядрами никого
> не удивишь.И ведь очевидно, что проще параллелится вариант, когда видео гоняется через shared mem или pipe, а не по общесистемной шине.
> только в названии, но и в предназначении и в частоте использования?Вроде я с этим и не спорил.
> не возбраняется. но лучше это дело максимально затруднить,Не согласен. Как я уже сказал - вижу и вполне валидные на мой взгляд юзкейсы.
> я его не собираюсь в шину сообщений кидать.
А как по мне - шина должна быть максимально generic к тому что летает и работать с скоростью составляющей существенный процент оперативы. Хотя если кому нравится как в результате появляются ушлenки типа вeдрoида и костыли типа binder - это как бы да, но в результате потм появляются android-only дрoва, а вы там если хотите - libhybris'ом костыльте. Я за то чтобы по первому сорту работал не только ведроид и не надо было ставить такие костыли ядру, извините. Максимально generic и шустрая шина была бы не лишней.
Так что если некто хочет слать бинарные данные - это ок. В байте 256 возможных значений и искусственно обрyбать себя лишь менее чем половиной из них - просто глупо ИМХО. Это элеметарное недоиспользование возможностей машин. И да, системные шины - для программ, а не людей. По поводу чего снижать эффективность и урезать половину юзкейсов совершенно не оправданно имхо. Это все-равно никто в нормальной ситуации не читает.
> класть в какой-нибудь /tmp, и передавать имя файла по этому поводу.
В несколько раз больше действй + файловые операции. А если это реальная ФС - еще и адская гажка метаданными и фрагментами в ФС. Наф-наф-наф.
> ядерную шину сообщений — лично в моём мире называется непечатными словами.
Не вижу ничего такого зазорного - в разы меньше операций и нет риска нагaдить метаданными в ФС. На кой фрагментить данные и метаданные лишний раз? Слишком быстро работает? Или мсье любитель tmpfs в раме? Как-то весьма авангардично для слаквариста, не?
> ну зачем же такие дракoнoвские ограничения? что, голос, значит, нормально, а если
> я видео хочу проиграть — то всё, уже никак?Там бандвиз который идет на экран - заметный процент бандвиза рам. Так что всякие продвинутости могут не получиться по чисто техническим причинам. Хотя с zero copy может пожалуй и нормально пролезть, скажем толкать целый кадр за раз. Это много данных, его страницы просто отремапят в процесс назначения, копирования не будет, а 60 или даже 120 зарядов ремапа в секунду - не так уж и много. Особенно если под это большие страницы юзать, чтоб ремап быстро происходил. И DMA заряжать при нужде делать мультикаст.
> ловит и дальше уже в raw-виде выплёвывает. кому-нибудь ещё. отличное же
> решение!Решение как решение. С zero copy наверное не сильно хуже чем многие другие. Там все вообще не очень просто. И да, более 1 назначения для RAW кадров - это нормально в современном мире, прикинь?
Вот смотри: снимаем видео. С камеры надо загнать поток в кодек чтобы тот сжал. А еще надо на экран - видоискатель для юзера, однако. То-есть даже у такой простой задачи точек назначения видео на самом деле минимум две.
На правах изврата - шине можно было бы заказывать bulk xfer а там обслyга могла бы например автомат DMA заряжать под bulk транзакции, сделав нечто типа подпертого железом мультикаста, где размножение данных спихнуто с проца на автомат, при том программируемый весьма косвенно. А сейчас это все как-то очень сложно делается и нифига не гибко.
> не, без raw-видео в разрешении 100500x100500 никак. давайте всё в шину пихать.
> кстати, операции с файлами тоже не нyжны, это всё тоже через шину. и сеть туда же.Если с zero copy, да тяжелые транзакции требующие "мультикаста" хардварными автоматами подпереть - можно наверное и в шину. Правда смысл этого под вопросом - а что, есть ощущение что станет лучше работать? Или чисто из соображений расовой верноты?
> только вот это совсем так чуть-чуть другая система получается. с совсем другими
> принципами и архитектурой. не надо пихать невпихyемое.Отсутсвие нормальной системной шины всю жизнь было одним из самых больших минусов пингвина. И если делать - так уж нормально.
> нет, это не «голосовое управление», это гoвнoсофт, который сносится сразу по
> обнаружении того, что он пытается пихать в шину подобный мусор.Твои предложения насчет архитектуры подобных вещей? И чтоб не париться что распознавалок пять штук открытых, пара дюжин разновидностей железяк и что там еще. То же с синтезаторами и прочая. А если мы хотим еще скажем с VoIP скрестить? Не зная заранее что за программа там будет? Ну там синтез речи делать или субтитры показывать (глухим и немым пользователям явно понравится, да и не только им, etc). Возможность пристыковаться к стандартному и-фейсу для таких вещей смотрелась бы логично.
> кстати, я так понимаю, что посылки ты тоже исключительно письмами хочешь слать?
> а чего, ведь почта же, пусть жуёт.Ну знаешь, если поттеринг для zero copy провел границу 512Кб - это уже целая бандероль, однако. И да, ты знаешь - один из самых эффективных вариантов оказался "почтовый пакет". Еще не посылка, но уже можно набить намного больше чем в письмо.
> посылка «хрупкое» или вагон кирпичей… всё надо одним и тем же транспортом!
Как ни странно - по этому поводу большинство товаров из всяких китайских интернет магазинов и т.п. - пытаются вписываться в формат "почтовый пакет", а популярность этого формата здорово увеличилась, подвинув и письма и посылки :).
1. ты хочешь компонентную систему, но не знаешь, что это. поэтому пытаешься из шины сообщений сделать костыль для того, о чём ты не знаешь.2. я всё ещё хочу узнать: кирпичи, фарфор и письма надо возить одним и тем же транспортом, в одних и тех же условиях?
> 2. я всё ещё хочу узнать: кирпичи, фарфор и письма надо возить одним и тем же транспортом, в одних и тех же условиях?Вагоны разные, да.
Но рельсы — одни и теже.
и рельсы тоже разные, вам просто не рассказывают.
> Так чтобы программам не надо было знать интимные особенности движков и который из них вообще в вон той системе, а движкам ни к чему знать что это за программа и где она эти данные берет.Надо же какой ты умный, без dbus то инженеры за десятилетя развития айти индустрии так и не придумали как решать подобные проблемы.
Программы и так не знают какие особенности движков, дёргают их примерно точно через такое же библиотечное api из которого ничего не видно (где вообше такой сценарий допустим). Точки раздела между компонентами в виде абстрактных api придумали хер знает сколько десятков лет назад и столько же лет успешно им всюду пользуются.
Если даже запилить это гогнецо через dbus, то приложения не будут использовать его прямо через сообщения, вместо будут дёргать некую обёрточную библиотеку которая будет решать как именно нужно достучаться до сервиса - dbus, unix сокет, прямое использование библиотеки и ещё что.
> А я вижу некоторые валидные сценарии.
Это чушь от дилетанта, даже близко не угадал зачем может понадобиться пользоваться dbus подобной технологией.
> Надо же какой ты умный, без dbus то инженеры за десятилетя развития
> айти индустрии так и не придумали как решать подобные проблемы.Покажи решения. Есть пара проприетарин, гоняющих данные аж на ремотные сервера (долой приваси и не работает без интернета, что очень в духе гугли) или просто 1 проприетарный движок прибитый гвоздями - можно вот так и более вообще совсем никак.
> через такое же библиотечное api из которого ничего не видно (где
> вообше такой сценарий допустим).Это тоже вариант, но в упомянутом случае может требоваться и мультикаст и работа с разными источниками и шина смотрится не так уж странно.
> лет успешно им всюду пользуются.
И где примеры успешного использования?
> Если даже запилить это гогнецо через dbus, то приложения не будут использовать
> его прямо через сообщения, вместо будут дёргать некую обёрточную библиотекуА зачем? Потребуется лишь некий минимальный коннектор который адаптирует то что там внутри движка к шине. И все. Было бы довольно логично вроде.
> которая будет решать как именно нужно достучаться до сервиса - dbus, unix
> сокет, прямое использование библиотеки и ещё что.В принципе тоже вариант. Но с шиной больше разных вариантов с множественными подписчиками или источниками сигнала и это бы делалось попроще в ряде случаев. Грубо говоря, если я дергаю либу а там кто-то уже синтезатором спича трындит - это довольно отдельный случай. В этом случае они или все-равно будут городить шинообразную очередизацию и прочее и получится куча подобного кода но в какой-то либе, а потом в другой либе еще куча такого же кода, или оно будет работать как г-но. Тогда как 1 раз сделать быструю шину с приоритетами и прочим - проще чем все это же но в 20 разных закоулках.
> Это чушь от дилетанта, даже близко не угадал зачем может понадобиться пользоваться
> dbus подобной технологией.На самом деле много зачем. А этот пример несколько натянутый но - вполне себе вариант зачем там аудио протолкать может захотеться.
> Покажи решения. Есть пара проприетарин, гоняющих данные аж на ремотные сервера (долой приваси и не работает без интернета, что очень в духе гугли)Ты что, законченный наркоман и не понимаешь разницы между обобщённым API (это именно твой пример выше юз-кейса dbus'а если не понятно) и системой распознавания речи? Я, конечно, понимаю что у тебя смешались в одну кучу котлеты и мухи, есть какие-то эмоции на счёт dbus от чего в итоге выходят суждения вроде ~ говорящий дурачёк с телефоном круто и хайтечно, dbus круто... и почему бы двум прекрасным вещам не быть вместе ?! Не желая понимать при этом технических аспектов такой дружбы.
Эмоции в инженерии неуместны, нужно равнодушно всё раскладывать по полочкам и ясно понимать зачем и как что-то нужно делать. Об этом было немного выше, теперь будет ещё и ниже.
> Это тоже вариант, но в упомянутом случае может требоваться и мультикаст и работа с разными источниками и шина смотрится не так уж странно.
не может этого требоваться, ни для синтеза речи, ни для распознавания.
> В принципе тоже вариант. Но с шиной больше разных вариантов с множественными подписчиками или источниками сигнала и это бы делалось попроще в ряде случаев.
Это единственный вариант.
Есть только однин юз-кейс систем распознавания и синтеза речи для dbus - голосовой UI. И выглядит он совсем просто - сообщение "спроси у пользователя" и "скажи ему чего-то", т.е. никакого звукового контента по шине ходить не будет, сервис сам забирает звук откуда нужно, ранжирует их во времени, определяет активного подписчика и прочее.
> В этом случае они или все-равно будут городить шинообразную очередизацию и прочее и получится куча подобного кода но в какой-то либе, а потом в другой либе еще куча такого же кода, или оно будет работать как г-но.
Кто, они, зачем куйню несёшь? Впрочем, если будут писать чудилы вроде тебя, то конечно, будет подобный угар. Такое, к сожалению, бывает, о чём собственно весь срач выше в новости.
Меня волнует тольео один вопрос - с этим kdbus систему кроме systemd чем-то бутнуть можно будет?