В списке рассылки разработчиков ядра Linux предложена (https://lkml.org/lkml/2016/10/26/963) для обсуждения реализация новой шины обмена сообщениями Bus1 (http://www.bus1.org/), пришедшей на смену шине kdbus (https://www.opennet.ru/opennews/art.shtml?num=41810), которую в свой время не удалось продвинуть в основной состав ядра. Bus1 разработан с нуля и концептуально ближе к IPC-маханизмам Android Binder (https://developer.android.com/reference/android/os/Binder.ht... Cap'n Proto (https://capnproto.org/) и seL4 (https://sel4.systems/), чем к kdbus. Bus1 реализован в виде универсального модуля для ядра Linux, не требующего наличия каких-либо обязательных компонентов в пространстве пользователя. Код Bus1 распространяется (https://github.com/bus1/bus1) под лицензией LGPLv2.1+.Bus1 предоставляет объектно-ориентированный IPC-интерфейс для организации обмена данными между процессами (пирами), сочетающий легковесность и масштабируемость организации совместной работы с такими возможностями, как модульность, разделение привилегий, учёт ресурсов, изоляция и сокрытие информации (https://en.wikipedia.org/wiki/Information_hiding). Работа с объектами реализована через легковесные дескрипторы. Поддерживается доставка данных как в режиме точка-точка, так и в режиме мультикаст (от одного отправителя к группе получателей) с гарантированным сохранением порядка следования данных. На базе Bus1 в пространстве пользователя могут быть реализованы различные UAPI для обмена сообщениями, включая Binder UAPI.
Bus1 работает децентрализовано и только в локальных контекстах, не предоставляя общего глобального состояния совместного доступа или глобальных блокировок. Ключевыми примитивами в Bus1 являются узлы и дескрипторы: узлы представляют объекты локальных пиров (https://ru.wikipedia.org/wiki/Peer), а дескриптор выполняет роль указателя на узел. Узлы могут создаваться любым пиром, всегда оставаясь закреплёнными за своим создателем. Дескрипторы, ссылающиеся на узлы, могут передаваться с прикреплением сообщений в качестве вспомогательных данных. После доставки дескриптора, на стороне получателя создаётся его копия, которая указывает на тот же узел, что и оригинальный дескриптор.
Любой пир может отправлять сообщения через один из своих дескрипторов, которые будут направлены владельцу связанного с дескриптором узла. Если пир не предоставил дескриптор, то сообщение заданному узлу отправить невозможно. Дескриптор в данном случае выступает в роли механизма для предоставления эксклюзивного доступа, при этом доступ можно делегировать другим пирам просто передавая дескриптор. Права доступа не отзываются, но владелец узла в любой момент может его удалить и разрушить таким образом все привязанные дескрипторы. Пиры не могут адресоваться напрямую, полностью отделены и могут взаимодействовать с другими пирами только через узлы и дескрипторы. Со стороны все узлы равнозначны и невозможно определить принадлежат узлы одному пиру или разным.URL: https://lkml.org/lkml/2016/10/26/963
Новость: https://www.opennet.ru/opennews/art.shtml?num=45382
Ну вот, движение к концепции микроядра идёт неизбежно.
Если 25 лет назад ничто не смогло убедить Торвальдса, то ныне всякие угрозы безопасности и требования к надёжности - таки говорят своё веское слово.
> Если 25 лет назад ничто не смогло убедить Торвальдса, то ныне всякие угрозы безопасности и требования к надёжности - таки говорят своё веское слово.Думаю, определенную роль сыграли недавние remote root with one IP packet (CVE-2016-7117) и remote DoS with one IP packet (CVE-2016-7039, CVE-2016-8666).
это как-то противоречит изначальному тезису?
> Ну вот, движение к концепции микроядра идёт неизбежно.Будет вам "микро"-ядро от Лёнарта...
> Если 25 лет назад ничто не смогло убедить Торвальдса, то ныне всякие
Ну, есть ещё надежда: послушаем, куда он пошлёт птенцов на этот раз.
> угрозы безопасности и требования к надёжности - таки говорят своё веское
> слово.
Надеюсь, далеко пошлёт. Бред, а не архитектура. SysV IPC допилить - и то больше шансов.
> Надеюсь, далеко пошлёт. Бред, а не архитектура. SysV IPC допилить - и то больше шансов.Для тех, кто в курсе про разные назначения разных видов IPC, звучит как "TCP фигня, ICMP допилить - и то больше шансов".
Расширить до нужного состояния SysV очереди хотя бы возможно. А это... Какой-то архитектурный урод с самого начала.
> Расширить до нужного состояния SysV очереди хотя бы возможно.Мультикаст фифо с неограниченным количеством подписчиков - это круто. Ждем от вас патча.
Не вижу ничего ужасного. Можно управление подписчиками вытащить в отдельного демона, если уж так страшно. А можно и не вытаскивать. Можно и число подписчиков сделать ограниченным - тоже невелика беда, для любых реальных задач 128 непосредственных подписчиков, пожалуй, хватит. А больше нужно только для редких system-wide событий, которые один хрен будут обрабатываться какими-нибудь демонами per-user.
Не болтай, делай, а когда сделаешь тогда и приходи болтать.
Поздравляю, ты изобрел dbus. Именно его и хотели отправить на свалку, заменив kdbus
> 128 непосредственных подписчиков, пожалуй, хватит.Ух ты, 640 килобайтов хватит всем более не в моде. Пожалуй я погорячился с предложением пойти в рассылку и предложить архитектуру. Если ты такой архитектор - лучше вещай на опеннете.
да куда проще допилить парой мелких патчей SystemD и будет она рулить процессами легковесно и надёжно. чего вы в самом деле? (для совсем слепых добавлю тэг #sarcasm)
> Надеюсь, далеко пошлёт. Бред, а не архитектура. SysV IPC допилить - и
> то больше шансов.Так если тебе не нравится архитектура - выскажись в рассылке. Предложи архитектуру лучше. Но придется обосновать и на уровне более приличном чем опеннетовский.
> Будет вам "микро"-ядро от Лёнарта...По сравнению с леннартоподелием любое ядро скоро будет выглядеть "микро".
> По сравнению с леннартопoделием любое ядро скоро будет выглядеть "микро".Ну дык, по количеству строк кода уже примерно на равных с ядром пингвина в первой слаке.
>> По сравнению с леннартопoделием любоеЗЫ:
Прикольно -- "леннартопoделие" анонимам писать (условно) не разрешается ))
> Прикольно -- "леннартопoделие" анонимам писать (условно) не разрешается ))Нельзя писать "пoделие". А уж леннарто- или линусо- - дело десятое.
> Ну дык, по количеству строк кода уже примерно на равных с ядром пингвина в первой слаке.Но в ведре количество kloc все равно растет на пару порядков быстрее, чем у системды, так что без шансов.
> Но в ведре количество kloc все равно растет на пару порядков быстрее,
> чем у системды, так что без шансов.Проклятые железячники пекут железо быстрее чем пирожки. Захочешь не похудеешь. Но если это собрано модулем или не собрано вообще (а зачем тебе на x86 системе поддержка аудио в ARMовской SoC например?) - так этот код у тебя в системе и не присутствует.
> Ну, есть ещё надежда: послушаем, куда он пошлёт птенцов на этот раз.Fuck you, Security! And you, Stability, too!
> Ну вот, движение к концепции микроядра идёт неизбежно.модуль монолитного ядра (bus1.ko) к микроядрам приближает не больше чем любой другой модуль. Концепция микроядра давно протухла - нет туда никакого движения кроме RTOS для микроконтроллеров да специализированных гипервизоров, все успешные современные коммерческие ОС монолитные. Capability-based IPC и микроядра - это теплое с мягким, просто в UNIX традиционно разграничение прав на уровне пользователей было.
Експертное мнение?Ламер, не знающий на чем крутится его смартфон (OKL4/seL4), на чем крутится прошивка любого авто, архитектуру богомерзкой винды (а, это наверное неуспешная ОС) и т.д. :)
открою вам страшную тайну: в винде ядро тоже монолит
> открою вам страшную тайну: в винде ядро тоже монолитОно там скорее гибрид, но в целом те же яйца, вид в профиль.
>Ну вот, движение к концепции микроядра идёт неизбежно.Микроядра взлетят, когда появится аппаратная поддержка для них. Вспомните, после чего начался стремительный взлёт технологий виртуализации? После появления VT-x и AMD-V.
> Микроядра взлетят, когда появится аппаратная поддержка для них.Значит это не случится. Memory mapped периферия - наверное не то с чем хотело бы ориентировать микроядро. Потому что подразумевает маппинг периферии в память и прямую (а потому быструю) работу с ней из ядра.
MMIO здесь скорее помогает, т.к. позволяет юзерспейс процессам работать напрямую с устройствами. Не со всеми и на на всех платформах, но тем не менее.
Так у микроядря требований поменьше, чем у гипервизора. Того, что надо второму первому за глаза.
Другое дело, что понаделали костылей - ни тебе вложенности ни параллельной работы. И как после этого запускать гипервизор в микроядре или два рядом?
> Ну вот, движение к концепции микроядра идёт неизбежно.Не очень понятно каким боком системная шина связана с микроядром. Системную шину может реализовывать гибрид или монолит. И врядли линукс стал более микроядерным от реализации системной шины (даже не первой).
Тем не менее, извращенцы хотящие странного могут
- Запилить файлухи в user mode
- Запилить драйверы ряда устройств в user mode
- Запилить некоторые механизмы в user mode, включая всякие веселости типа user-mode page fault handlers, всякие там BPF VM и прочую работу с пакетами вафли и не только.Но обычно все это не делают, применяя все это только для специфичных случаев.
Интересная штука.Надеюсь, не случится, как с reiser4 и kdbus ("автор Линусу не нравится - проект идет лесом").
И как с -ck sheduler. Линус сказал что шедулер должен быть один.
> И как с -ck sheduler. Линус сказал что шедулер должен быть один.Вы про BFS? Лично я в его защиту слышал только про "субъективные ощущения" любителей тюнинга. Более-менее реалистичных тестов, показывающих его превосходство, не припоминаю.
Я про момент, когда CFS ещё не было. Linux 2.6.18, когда-то тогда
> Вы про BFS? Лично я в его защиту слышал только про "субъективные
> ощущения" любителей тюнинга. Более-менее реалистичных тестов, показывающих его превосходство,
> не припоминаю.ck - Con Kolivas
https://xkcd.com/619/
с Reiser4 там не только автор не нравился. впрочем ZFS это не помешало.
> Надеюсь, не случится, как с reiser4 и kdbus ("автор Линусу не нравится
> - проект идет лесом").Вообще-то в случае kdbus Торвальдс хотел взять в ядро, потому что Кроа-Хартман просил. Но тут Andy Lutomirsky устроил качественный технический разнос. А поскольку он полезный и грамотный коммитер - его мнение сложно не учесть. Ну он и высказал все что думает по поводу принесения всех проблем и грабель dbus. После его отповедей перцы и ушли обратно к drawing board. И сделали сабж.
Сам по себе сабж на вид в разы проше и вроде ничем таким не ужасен. Но вот чего я не понимаю так это как будет организован например discovery service'ов в такой топологии и как это будет стандартно, чтобы софт друг друга понимал.
drawing discovery service boardы
О, уже kdbus закапывают. Значит скоро закопают PulseAudio, Avahi, NetworkManager, PolicyKit и Dbus. А ещё Udisks3 выйдет. Ну а чо? 10 лет уже, старьё, старьё. А вдруг уже кто-нибудь переучился на них, и может настроить сервак промышленного уровня, не прибегая к платной техподдержке ред хата?
>Udisks3Так уже.
kdbus зак*пали уже давно. примерно сразу же после того, как стало ясно, что в апстрим не примут.
любая стабильность — уже застой (по мнению основных движителей никсов)
> уже, старьё, старьё. А вдруг уже кто-нибудь переучился на них, и
> может настроить сервак промышленного уровня, не прибегая к платной техподдержке ред хата?Редхат вообще удоды. Могли бы написать идеальную систему 10 лет назад и всем стало бы хорошо. А они вместо этого какие-то патчи к ядру присылают и деньги стригут. Но ты можешь испортить им бизнес: выпусти идеальную систему, пусть редхат обломается.
Судя по описанию - больно уж извращённо. Чем простой обмен сообщениями не угодил? Здесь вместо "отправил и забыл" (может, даже завершил процесс), получается, нужно держать активным своего пира пока не решишь, что все, кто хотел, получили возможность отреагировать на пойманный дескриптор.
Тем, что интерпроцесс в юзерленде очень медленный.
И поэтому мы сначала кинем дескриптор, а потом отдадим на запрос данные - то есть вместо одного обмена сделаем три. Это, конечно, будет много быстрее, чем за раз данные закинуть в ядро.
> И поэтому мы сначала кинем дескриптор, а потом отдадим на запрос данные
> - то есть вместо одного обмена сделаем три. Это, конечно, будет
> много быстрее, чем за раз данные закинуть в ядро.А в случая с сокетами, кидание дескриптора соответствует созданию сокета и подключению к нему. Видимо, сокеты - такой же архитектурный ужас.
Предлагаете на любой чих создавать новый сокет, кидать в него одно сообщение и его закрывать? Да, если так - то это архитектурный ужас.
> Предлагаете на любой чих создавать новый сокет, кидать в него одно сообщение и его закрывать? Да, если так - то это архитектурный ужас.Архитектурное решение в вашем стиле, да.
В bus1 тоже на каждое сообщение дескрипторами не обмениваются.
Так данные уже в ядре. Этож ЕМНИП внутриядерный обмен.
Там всё медленное. А учитывая, что оно для юзерленда только и нужно, нафига козе баян?
> Там всё медленное. А учитывая, что оно для юзерленда только и нужно, нафига козе баян?В смысле, "нафига делать быстро, если можно меееееедленно"?
> Там всё медленное. А учитывая, что оно для юзерленда только и нужно, нафига козе баян?Следующий шаг в рамках такой логики - создать специальный супермедленный IPC, чтобы учить пользователей смирению и прививать им любовь к апгрейдам.
> Тем, что интерпроцесс в юзерленде очень медленный.Ну да, обязательно нужна возможность погонять через IPC HD-pr0n, куда же без этого! Всякие zero-copy навороты -- немолодежное старье!
> Тем, что интерпроцесс в юзерленде очень медленный.И за счёт чего его собрались ускорять, пихая в ядро?
> И за счёт чего его собрались ускорять, пихая в ядро?За счет отсутствия переключений контекста, например. Линуксное ядро на эту тему вообще активно развивали - оно IIRC при сильной нагрузке аж сисколы группирует и перекидывает данные между режимами сразу батчами. Чтобы поменьше контексты переключать.
> Судя по описанию - больно уж извращённо. Чем простой обмен сообщениями не
> угодил? Здесь вместо "отправил и забыл" (может, даже завершил процесс), получается,
> нужно держать активным своего пира пока не решишь, что все, кто
> хотел, получили возможность отреагировать на пойманный дескриптор.И как на этом сделать подписку на определенные события? А мультикаст?
(Ответ "не нужно" не катит, это всего лишь индикатор мизерного программистского опыта отвечающего)
Ровно так же, как и с этой штукой - данная часть не будет отличаться, по идее. Более того - эмуляция предлагаемого безумного режима делалась бы тривиально - просто сообщение маркировалось бы как имеющее "расширенное тело" и ID, по которому можно это самое тело запросить.
Что-то мне подсказывает, что сокеты в режиме SEQ_PACKET + библитека сериализации из юзерспейса решат все проблемы.
Фатальную Проблему она не решает.
> Что-то мне подсказывает, что сокеты в режиме SEQ_PACKET + библитека сериализации из
> юзерспейса решат все проблемы.А как на этом сделать мультикаст?
> мультикастПеребрать всех известных клиентов в цикле и не загромождать API ядра. Клиентов максимум пару сотен будет (а реально штук 10-20).
> Перебрать всех известных клиентов в цикле и не загромождать API ядра.А если список клиентов заранее неизвестен?
Примеры: подписки на события типа "смена часового пояса" (важно всем программам, работающим с локальным временем), "поднятие сетевого интерфейса" и т.д.
> А если список клиентов заранее неизвестен?Все там известно. "Если пир не предоставил дескриптор, то сообщение заданному узлу отправить невозможно." Т.е. отправитель должен знать кому он отправляет сообщения, но можно отправить всем сразу одним вызовом.
ИМХО, мультикаст на уровне ядра может оптимизировать только количество переключений контекста "ядро<->юзерспейс" (т.к. цикл будет гонять ядро в одном системном вызове). Может быть, получится снизить количество копирований мультикаст-сообщения (не уверен, тут надо глубоко вникать). Для сообщений уровня "вставлена флешка" и "переход на питание от батареи" пофиг на оверхед.
> Все там известно. "Если пир не предоставил дескриптор, то сообщение заданному узлу
> отправить невозможно." Т.е. отправитель должен знать кому он отправляет сообщения, но
> можно отправить всем сразу одним вызовом.Каждому по отдельности? It's super effective!
// Из-за таких "эффективных программистов" вроде бы простые приложения еле ворочаются на современной технике, хотя по функциональности они недалеко ушли от софта времен 80386.
О, сразу про "эффективных программистов" вспомнил.Ничего, что Линус в прошлый раз завернул эту компашку с резолюцией "у вас неэффективное гoвнo в юзерспейсе, перепишите там, потом приходите в ядро"?
> О, сразу про "эффективных программистов" вспомнил.А если про них не вспоминать - так dbus уже есть. Да и binder с другой стороны. Поэтому изобретать что-то новое имеет смысл если видится возможность что-то улучшить.
> Каждому по отдельности? It's super effective!Не придирайся. "броадкаст неизвестному количеству клиентов" вообще плохо сочетается с требованием "гарантированной доставки". Поэтому циклы придется гонять в любом случае, вопрос только кому именно...
Так судя по их презентации оно и отправляет этот "мультикаст" именно каждому пиру в отдельности, просто делает это так, что все получат его "одновременно", чтобы гарантировать очередность доставки - это какой-то достаточно специфический сценарий, который видимо только редхату и нужен и который они позиционируют как фатальный недостаток всех других ipc.
есть netlink который умеет и multicast тоже.
> есть netlink который умеет и multicast тоже.А можно пример проги, которая использует netlink и запускается не от рута, а от юзера?
>> есть netlink который умеет и multicast тоже.
> А можно пример проги, которая использует netlink и запускается не от рута,
> а от юзера?iproute2
мультикаст в netlink можно только от рута использовать
> А можно пример проги, которая использует netlink и запускается не от рута, а от юзера?iw например.
Мне казалось, что этой новости пара месяцев уже. Где-то с сентября же разговоры идут. :)
Ну точно: 17 августа.
http://lwn.net/Articles/697191/
> Мне казалось, что этой новости пара месяцев уже. Где-то с сентября же
> разговоры идут. :)Насколько я помню, еще с начала года.
>> Мне казалось, что этой новости пара месяцев уже. Где-то с сентября жеЭта новость наверху -- отдельная невиданная доселе веха, "новый" код явлен Миру. Ларабель Похорониксович празднует. Ждём длиииинной череды постов про "Кернел N+0.1: BUS1 снова-опять-почему-то-ждём-скучаем не в мейнлайне" от задорного парня Микаэля.
>> разговоры идут. :)
> Насколько я помню, еще с начала года.Сначала их долго выпинывали, наконец до них дошло... Но не совсем: они почему-то решили, что нарисовать с нуля и сменить вывеску "должно всё изменить"ТМ. Придумали название и пошли писать код.
09.12.2015 BUS1: A New Linux Kernel IPC Bus Being Made By Systemd Developers
http://www.phoronix.com/scan.php?page=news_item&px=BUS1-In-D...09.11.2015 KDBUS Is Indeed Going Back To The Drawing Board
http://www.phoronix.com/scan.php?page=news_item&px=KDBUS-Bac...30.10.2015 KDBUS Is Being Removed From Fedora, Could Be A While Before Being Mainlined
http://www.phoronix.com/scan.php?page=news_item&px=Fedora-Dr...10.07.2015 The NSA Is Looking At Systemd's KDBUS
http://www.phoronix.com/scan.php?page=news_item&px=NSA-KDBUS...
> A New Linux Kernel IPC Bus Being Made By Systemd DevelopersПогодите, так это те же самые ребята? Мда. Ну, значит дело опять тухляк.
> Погодите, так это те же самые ребята? Мда. Ну, значит дело опять тухляк.Да, эти ребята не только сделают шину но ей еще и софт сможет реально пользоваться. А не как у других ребят - какая-то номинальная куита для галочки, которой может и не быть в 80% систем, так что вы там держитесь и кодьте покамест fallback сами. Что вам, впадлу самому системную шину реализовать как умеете?
самое интересное: надеюсь протокол - текстовый?
Каанешно! :-)http://gentooexperimental.org/~patrick/weblog/archives/2014-...
ну надеюсь на этот раз Торвальдс взорвется и даст уже оценку поделию пОТТЕРА!а в идеале за недельку сам напишет человеческий аналог который везде продвинут
> ну надеюсь на этот раз Торвальдс взорвется и даст уже оценку пoделию пОТТЕРА!Он уже это сделал
> I don't personally mind systemd, and in fact my main desktop and laptop both run it© Linus
Это он дипломатично увернулся от неудобного вопроса. Представь, каково это: с одной стороны, тебе надо беречь и поддерживать репутацию справедливого и объективного лидера, а с другой - ты акционер Red Hat. И как вот выкручиваться от таких вопросов ребром?
> Это он дипломатично увернулся от неудобного вопроса. Представь, каково это: с одной
> стороны, тебе надо беречь и поддерживать репутацию справедливого и объективного лидера,
> а с другой - ты акционер Red Hat. И как вот
> выкручиваться от таких вопросов ребром?крупный акционер имеет веский голос в принятии решений или нет?
сомневаюсь, что RedHat владеют полностью отмороженные товарищи не понимающие куда все движется
значит, его все и так устраивает
Похоже, что он вовсе не такой крупный, как вам кажется.
https://investors.redhat.com/stock-information/ownership-pro...
В любом случае, дело-то не в том, крупный ли он акционер, а в том, что он медийная личность, и неаккуратно проболтавшись о технической стороне вопроса он может сильно нагреть самого себя прежде всего.>сомневаюсь, что RedHat владеют полностью отмороженные товарищи не понимающие куда все движется
Они-то как раз все понимают. Леня им сотворил гигантский зонд, который по сути вендорлочит вообще все линукс-коммьюнити на ред хате. А раз оно формально free software, то вроде бы и не придерешься.
> Это он дипломатично увернулся от неудобного вопроса.Это скорее хейтеры демонстрируют wishful thinking во весь рост. А так Торвальдс может без обиняков заявить Каю Сиверсу (или любому другому) что тот full of sh*t если тот косячит. С предложением вытряхнуть sh*t и прийти в адекват. А кто сказал что Сиверс или там кто еще на это не способны? Судя по кардинальной переделке сабжа - вполне себе.
> ну надеюсь на этот раз Торвальдс взорвется и даст уже оценку поделию
> пОТТЕРА!
> а в идеале за недельку сам напишет человеческий аналог который везде продвинутТы всё перепутал: там, когда было переписывание за недельку, Линусу не давали пользоать, но дали "списать", а тут всё наоборот: пользование пхают во все дыры, а от "списывания" он "диполоматично уварачивается"ц, аотому как нет там :/ предмета для творческой кражи.
Совсем не похоже.
попетросяню. systemdBus1 ?
> попетросяню. systemdBus1 ?Нет, s-d-libkerneld. Всё остальное ядро будет пришлёпкой сбоку к Великому Поделию. Щупальца №2, ну, бишь bus1, запускается, запускается щупальца... в ядро...
>сокрытие информациист 237 УК РФ
Ох, жарко то как, аж криокамера у меня поломалась!Ну заменят допустим kdbus на bus1, но самый обычный DBus никуда не денется-то... если вдруг даже на десктопе и нужен будет DBus с ядерной скоростью, то напишут для отдельных просителей и ответчиков обёртку типа apulse и xwayland, и libdbus для LD_PRELOAD
Совместимость древнего и заброшенного поломается не сильно, зато можно будет сочетать безопасность со скоростью.