The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Для ядра Linux вместо kdbus предложен механизм межпроцессных коммуникаций Bus1

27.10.2016 11:53

В списке рассылки разработчиков ядра Linux предложена для обсуждения реализация новой системы межпроцессных коммуникаций Bus1, пришедшей на смену шине kdbus, которую в своё время не удалось продвинуть в основной состав ядра. Bus1 разработан с нуля и концептуально ближе к IPC-механизмам Android Binder, Cap'n Proto, Mojo и seL4, чем к kdbus. Bus1 реализован в виде универсального модуля для ядра Linux, не требующего наличия каких-либо обязательных компонентов в пространстве пользователя. Код Bus1 распространяется под лицензией LGPLv2.1+.

Bus1 предоставляет объектно-ориентированный IPC-интерфейс для организации обмена данными между процессами (пирами), сочетающий легковесность и масштабируемость организации совместной работы с такими возможностями, как модульность, разделение привилегий, учёт ресурсов, изоляция и сокрытие информации. Работа с объектами реализована через легковесные дескрипторы. Поддерживается доставка данных как в режиме точка-точка, так и в режиме мультикаст (от одного отправителя к группе получателей) с гарантированным сохранением порядка следования данных. На базе Bus1 в пространстве пользователя могут быть реализованы различные UAPI для обмена сообщениями, включая Binder UAPI.

Bus1 работает децентрализовано и только в локальных контекстах, не предоставляя общего глобального состояния совместного доступа или глобальных блокировок. Ключевыми примитивами в Bus1 являются узлы и дескрипторы: узлы представляют объекты локальных пиров, а дескриптор выполняет роль указателя на узел. Узлы могут создаваться любым пиром, всегда оставаясь закреплёнными за своим создателем. Дескрипторы, ссылающиеся на узлы, могут передаваться с прикреплением сообщений в качестве вспомогательных данных. После доставки дескриптора, на стороне получателя создаётся его копия, которая указывает на тот же узел, что и оригинальный дескриптор.

Любой пир может отправлять сообщения через один из своих дескрипторов, которые будут направлены владельцу связанного с дескриптором узла. Если пир не предоставил дескриптор, то сообщение заданному узлу отправить невозможно. Дескриптор в данном случае выступает в роли механизма для предоставления эксклюзивного доступа, при этом доступ можно делегировать другим пирам просто передавая дескриптор. Права доступа не отзываются, но владелец узла в любой момент может его удалить и разрушить таким образом все привязанные дескрипторы. Пиры не могут адресоваться напрямую, полностью отделены и могут взаимодействовать с другими пирами только через узлы и дескрипторы. Со стороны все узлы равнозначны и невозможно определить принадлежат узлы одному пиру или разным.

  1. Главная ссылка к новости (https://lkml.org/lkml/2016/10/...)
  2. OpenNews: Четвёртый выпуск реализации kdbus для ядра Linux
  3. OpenNews: Третий выпуск реализации kdbus для ядра Linux
  4. OpenNews: Представлена обновлённая реализация kdbus для ядра Linux
  5. OpenNews: В Systemd обеспечена поддержка загрузки с использованием kdbus
  6. OpenNews: Kdbus, DBus-подобный сервис ядра Linux, достиг состояния, пригодного для тестового использования
Лицензия: CC-BY
Тип: К сведению
Ключевые слова: bus1, dbus
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (94) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 19:23, 27/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Ну вот, движение к концепции микроядра идёт неизбежно.
    Если 25 лет назад ничто не смогло убедить Торвальдса, то ныне всякие угрозы безопасности и требования к надёжности - таки говорят своё веское слово.
     
     
  • 2.3, Аноним (-), 19:29, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Если 25 лет назад ничто не смогло убедить Торвальдса, то ныне всякие угрозы безопасности и требования к надёжности - таки говорят своё веское слово.

    Думаю, определенную роль сыграли недавние remote root with one IP packet (CVE-2016-7117) и remote DoS with one IP packet (CVE-2016-7039, CVE-2016-8666).

     
     
  • 3.70, Аноним (-), 01:04, 29/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    это как-то противоречит изначальному тезису?
     
  • 2.7, Andrey Mitrofanov (?), 19:45, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • –9 +/
    > Ну вот, движение к концепции микроядра идёт неизбежно.

    Будет вам "микро"-ядро от Лёнарта...

    > Если 25 лет назад ничто не смогло убедить Торвальдса, то ныне всякие

    Ну, есть ещё надежда: послушаем, куда он пошлёт птенцов на этот раз.

    > угрозы безопасности и требования к надёжности - таки говорят своё веское
    > слово.

     
     
  • 3.9, Crazy Alex (ok), 19:52, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • –9 +/
    Надеюсь, далеко пошлёт. Бред, а не архитектура. SysV IPC допилить - и то больше шансов.
     
     
  • 4.16, Аноним (-), 21:39, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • +9 +/
    > Надеюсь, далеко пошлёт. Бред, а не архитектура. SysV IPC допилить - и то больше шансов.

    Для тех, кто в курсе про разные назначения разных видов IPC, звучит как "TCP фигня, ICMP допилить - и то больше шансов".

     
     
  • 5.24, Crazy Alex (ok), 21:50, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Расширить до нужного состояния SysV очереди хотя бы возможно. А это... Какой-то архитектурный урод с самого начала.
     
     
  • 6.30, Аноним (-), 22:53, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > Расширить до нужного состояния SysV очереди хотя бы возможно.

    Мультикаст фифо с неограниченным количеством подписчиков - это круто. Ждем от вас патча.

     
     
  • 7.34, Crazy Alex (ok), 23:22, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Не вижу ничего ужасного. Можно управление подписчиками вытащить в отдельного демона, если уж так страшно. А можно и не вытаскивать. Можно и число подписчиков сделать ограниченным - тоже невелика беда, для любых реальных задач 128 непосредственных подписчиков, пожалуй, хватит. А больше нужно только для редких system-wide событий, которые один хрен будут обрабатываться какими-нибудь демонами per-user.
     
     
  • 8.51, Аноним (-), 08:15, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Не болтай, делай, а когда сделаешь тогда и приходи болтать ... текст свёрнут, показать
     
  • 8.69, Alex (??), 19:30, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Поздравляю, ты изобрел dbus Именно его и хотели отправить на свалку, заменив kd... текст свёрнут, показать
     
  • 8.89, Аноним (-), 01:56, 31/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Ух ты, 640 килобайтов хватит всем более не в моде Пожалуй я погорячился с предл... текст свёрнут, показать
     
  • 4.68, Baz (?), 19:07, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    да куда проще допилить парой мелких патчей SystemD и будет она рулить процессами легковесно и надёжно. чего вы в самом деле? (для совсем слепых добавлю тэг #sarcasm)
     
  • 4.85, Аноним (-), 01:46, 31/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Надеюсь, далеко пошлёт. Бред, а не архитектура. SysV IPC допилить - и
    > то больше шансов.

    Так если тебе не нравится архитектура - выскажись в рассылке. Предложи архитектуру лучше. Но придется обосновать и на уровне более приличном чем опеннетовский.

     
  • 3.12, Led (ok), 20:22, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Будет вам "микро"-ядро от Лёнарта...

    По сравнению с леннартоподелием любое ядро скоро будет выглядеть "микро".

     
     
  • 4.15, Аноним (-), 21:37, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > По сравнению с леннартопoделием любое ядро скоро будет выглядеть "микро".

    Ну дык, по количеству строк кода уже примерно на равных с ядром пингвина в первой слаке.

     
     
  • 5.18, Аноним (-), 21:42, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> По сравнению с леннартопoделием любое

    ЗЫ:
    Прикольно -- "леннартопoделие" анонимам писать (условно) не разрешается ))

     
     
  • 6.20, Аноним (-), 21:43, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Прикольно -- "леннартопoделие" анонимам писать (условно) не разрешается ))

    Нельзя писать "пoделие". А уж леннарто- или линусо- - дело десятое.

     
  • 5.23, Аноним (-), 21:48, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну дык, по количеству строк кода уже примерно на равных с ядром пингвина в первой слаке.

    Но в ведре количество kloc все равно растет на пару порядков быстрее, чем у системды, так что без шансов.

     
     
  • 6.88, Аноним (-), 01:54, 31/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Но в ведре количество kloc все равно растет на пару порядков быстрее,
    > чем у системды, так что без шансов.

    Проклятые железячники пекут железо быстрее чем пирожки. Захочешь не похудеешь. Но если это собрано модулем или не собрано вообще (а зачем тебе на x86 системе поддержка аудио в ARMовской SoC например?) - так этот код у тебя в системе и не присутствует.

     
  • 3.19, Аноним (-), 21:42, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ну, есть ещё надежда: послушаем, куда он пошлёт птенцов на этот раз.

    Fuck you, Security! And you, Stability, too!

     
  • 2.57, Аноним (-), 10:05, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Ну вот, движение к концепции микроядра идёт неизбежно.

    модуль монолитного ядра (bus1.ko) к микроядрам приближает не больше чем любой другой модуль. Концепция микроядра давно протухла - нет туда никакого движения кроме RTOS для микроконтроллеров да специализированных гипервизоров, все успешные современные коммерческие ОС монолитные. Capability-based IPC и микроядра - это теплое с мягким, просто в UNIX традиционно разграничение прав на уровне пользователей было.

     
     
  • 3.63, Вареник (?), 15:16, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Експертное мнение?

    Ламер, не знающий на чем крутится его смартфон (OKL4/seL4), на чем крутится прошивка любого авто, архитектуру богомерзкой винды (а, это наверное неуспешная ОС) и т.д. :)

     
     
  • 4.76, Аноним (-), 16:45, 30/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    открою вам страшную тайну: в винде ядро тоже монолит
     
     
  • 5.86, Аноним (-), 01:48, 31/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > открою вам страшную тайну: в винде ядро тоже монолит

    Оно там скорее гибрид, но в целом те же яйца, вид в профиль.

     
  • 2.60, Аноним (-), 12:02, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >Ну вот, движение к концепции микроядра идёт неизбежно.

    Микроядра взлетят, когда появится аппаратная поддержка для них. Вспомните, после чего начался стремительный взлёт технологий виртуализации? После появления VT-x и AMD-V.

     
     
  • 3.87, Аноним (-), 01:49, 31/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Микроядра взлетят, когда появится аппаратная поддержка для них.

    Значит это не случится. Memory mapped периферия - наверное не то с чем хотело бы ориентировать микроядро. Потому что подразумевает маппинг периферии в память и прямую (а потому быструю) работу с ней из ядра.

     
     
  • 4.93, decaprox (?), 16:51, 01/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    MMIO здесь скорее помогает, т.к. позволяет юзерспейс процессам работать напрямую с устройствами. Не со всеми и на на всех платформах, но тем не менее.
     
  • 3.91, КО (?), 12:38, 31/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Так у микроядря требований поменьше, чем у гипервизора. Того, что надо второму первому за глаза.
    Другое дело, что понаделали костылей - ни тебе вложенности ни параллельной работы. И как после этого запускать гипервизор в микроядре или два рядом?
     
  • 2.77, Аноним (-), 01:10, 31/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну вот, движение к концепции микроядра идёт неизбежно.

    Не очень понятно каким боком системная шина связана с микроядром. Системную шину может реализовывать гибрид или монолит. И врядли линукс стал более микроядерным от реализации системной шины (даже не первой).

    Тем не менее, извращенцы хотящие странного могут
    - Запилить файлухи в user mode
    - Запилить драйверы ряда устройств в user mode
    - Запилить некоторые механизмы в user mode, включая всякие веселости типа user-mode page fault handlers, всякие там BPF VM и прочую работу с пакетами вафли и не только.

    Но обычно все это не делают, применяя все это только для специфичных случаев.

     

  • 1.2, Аноним (-), 19:25, 27/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Интересная штука.

    Надеюсь, не случится, как с reiser4 и kdbus ("автор Линусу не нравится - проект идет лесом").

     
     
  • 2.39, Аноним (-), 01:20, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    И как с -ck sheduler. Линус сказал что шедулер должен быть один.
     
     
  • 3.41, Аноним (-), 01:31, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > И как с -ck sheduler. Линус сказал что шедулер должен быть один.

    Вы про BFS? Лично я в его защиту слышал только про "субъективные ощущения" любителей тюнинга. Более-менее реалистичных тестов, показывающих его превосходство, не припоминаю.

     
     
  • 4.66, Аноним (-), 16:13, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Я про момент, когда CFS ещё не было. Linux 2.6.18, когда-то тогда
     
  • 4.71, Аноним (-), 01:08, 29/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы про BFS? Лично я в его защиту слышал только про "субъективные
    > ощущения" любителей тюнинга. Более-менее реалистичных тестов, показывающих его превосходство,
    > не припоминаю.

    ck - Con Kolivas

     
  • 4.75, KonstantinB (ok), 12:36, 30/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    https://xkcd.com/619/
     
  • 2.64, Клыкастый (ok), 15:30, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    с Reiser4 там не только автор не нравился. впрочем ZFS это не помешало.
     
  • 2.78, Аноним (-), 01:14, 31/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Надеюсь, не случится, как с reiser4 и kdbus ("автор Линусу не нравится
    > - проект идет лесом").

    Вообще-то в случае kdbus Торвальдс хотел взять в ядро, потому что Кроа-Хартман просил. Но тут Andy Lutomirsky устроил качественный технический разнос. А поскольку он полезный и грамотный коммитер - его мнение сложно не учесть. Ну он и высказал все что думает по поводу принесения всех проблем и грабель dbus. После его отповедей перцы и ушли обратно к drawing board. И сделали сабж.

    Сам по себе сабж на вид в разы проше и вроде ничем таким не ужасен. Но вот чего я не понимаю так это как будет организован например discovery service'ов в такой топологии и как это будет стандартно, чтобы софт друг друга понимал.

     
     
  • 3.90, Аноним (-), 03:15, 31/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    drawing discovery service boardы
     

  • 1.4, Zenitur (ok), 19:31, 27/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    О, уже kdbus закапывают. Значит скоро закопают PulseAudio, Avahi, NetworkManager, PolicyKit и Dbus. А ещё Udisks3 выйдет. Ну а чо? 10 лет уже, старьё, старьё. А вдруг уже кто-нибудь переучился на них, и может настроить сервак промышленного уровня, не прибегая к платной техподдержке ред хата?
     
     
  • 2.49, anonymous (??), 08:11, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >Udisks3

    Так уже.

     
  • 2.61, Аноним (-), 14:40, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    kdbus зак*пали уже давно. примерно сразу же после того, как стало ясно, что в апстрим не примут.
     
  • 2.72, Аноним (-), 01:10, 29/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    любая стабильность — уже застой (по мнению основных движителей никсов)
     
  • 2.79, Аноним (-), 01:17, 31/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > уже, старьё, старьё. А вдруг уже кто-нибудь переучился на них, и
    > может настроить сервак промышленного уровня, не прибегая к платной техподдержке ред хата?

    Редхат вообще удоды. Могли бы написать идеальную систему 10 лет назад и всем стало бы хорошо. А они вместо этого какие-то патчи к ядру присылают и деньги стригут. Но ты можешь испортить им бизнес: выпусти идеальную систему, пусть редхат обломается.

     

  • 1.5, Crazy Alex (ok), 19:32, 27/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Судя по описанию - больно уж извращённо. Чем простой обмен сообщениями не угодил? Здесь вместо "отправил и забыл" (может, даже завершил процесс), получается, нужно держать активным своего пира пока не решишь, что все, кто хотел, получили возможность отреагировать на пойманный дескриптор.
     
     
  • 2.6, Bvz (?), 19:41, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тем, что интерпроцесс в юзерленде очень медленный.
     
     
  • 3.8, Crazy Alex (ok), 19:51, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И поэтому мы сначала кинем дескриптор, а потом отдадим на запрос данные - то есть вместо одного обмена сделаем три. Это, конечно, будет много быстрее, чем за раз данные закинуть в ядро.
     
     
  • 4.29, Аноним (-), 22:50, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > И поэтому мы сначала кинем дескриптор, а потом отдадим на запрос данные
    > - то есть вместо одного обмена сделаем три. Это, конечно, будет
    > много быстрее, чем за раз данные закинуть в ядро.

    А в случая с сокетами, кидание дескриптора соответствует созданию сокета и подключению к нему. Видимо, сокеты - такой же архитектурный ужас.

     
     
  • 5.35, Crazy Alex (ok), 23:23, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Предлагаете на любой чих создавать новый сокет, кидать в него одно сообщение и его закрывать? Да, если так - то это архитектурный ужас.
     
     
  • 6.42, Аноним (-), 01:33, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Предлагаете на любой чих создавать новый сокет, кидать в него одно сообщение и его закрывать? Да, если так - то это архитектурный ужас.

    Архитектурное решение в вашем стиле, да.

    В bus1 тоже на каждое сообщение дескрипторами не обмениваются.

     
  • 4.92, КО (?), 12:41, 31/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Так данные уже в ядре. Этож ЕМНИП внутриядерный обмен.
     
  • 3.10, Аноним (-), 19:53, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Там всё медленное. А учитывая, что оно для юзерленда только и нужно, нафига козе баян?
     
     
  • 4.21, Аноним (-), 21:45, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Там всё медленное. А учитывая, что оно для юзерленда только и нужно, нафига козе баян?

    В смысле, "нафига делать быстро, если можно меееееедленно"?

     
  • 4.44, Аноним (-), 01:38, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Там всё медленное. А учитывая, что оно для юзерленда только и нужно, нафига козе баян?

    Следующий шаг в рамках такой логики - создать специальный супермедленный IPC, чтобы учить пользователей смирению и прививать им любовь к апгрейдам.

     
  • 3.22, Аноним (-), 21:48, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Тем, что интерпроцесс в юзерленде очень медленный.

    Ну да, обязательно нужна возможность погонять через IPC HD-pr0n, куда же без этого! Всякие zero-copy навороты  -- немолодежное старье!

     
  • 3.50, anonymous (??), 08:12, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Тем, что интерпроцесс в юзерленде очень медленный.

    И за счёт чего его собрались ускорять, пихая в ядро?

     
     
  • 4.80, Аноним (-), 01:24, 31/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > И за счёт чего его собрались ускорять, пихая в ядро?

    За счет отсутствия переключений контекста, например. Линуксное ядро на эту тему вообще активно развивали - оно IIRC при сильной нагрузке аж сисколы группирует и перекидывает данные между режимами сразу батчами. Чтобы поменьше контексты переключать.

     
  • 2.17, Аноним (-), 21:41, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Судя по описанию - больно уж извращённо. Чем простой обмен сообщениями не
    > угодил? Здесь вместо "отправил и забыл" (может, даже завершил процесс), получается,
    > нужно держать активным своего пира пока не решишь, что все, кто
    > хотел, получили возможность отреагировать на пойманный дескриптор.

    И как на этом сделать подписку на определенные события? А мультикаст?
    (Ответ "не нужно" не катит, это всего лишь индикатор мизерного программистского опыта отвечающего)

     
     
  • 3.31, Crazy Alex (ok), 22:54, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Ровно так же, как и с этой штукой - данная часть не будет отличаться, по идее. Более того - эмуляция предлагаемого безумного режима делалась бы тривиально - просто сообщение маркировалось бы как имеющее "расширенное тело" и ID, по которому можно это самое тело запросить.
     

  • 1.11, Аноним (-), 20:00, 27/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Что-то мне подсказывает, что сокеты в режиме SEQ_PACKET + библитека сериализации из юзерспейса решат все проблемы.
     
     
  • 2.13, Аноним (-), 21:35, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Фатальную Проблему она не решает.
     
  • 2.14, Аноним (-), 21:37, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Что-то мне подсказывает, что сокеты в режиме SEQ_PACKET + библитека сериализации из
    > юзерспейса решат все проблемы.

    А как на этом сделать мультикаст?

     
     
  • 3.25, Аноним (-), 21:55, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > мультикаст

    Перебрать всех известных клиентов в цикле и не загромождать API ядра. Клиентов максимум пару сотен будет (а реально штук 10-20).

     
     
  • 4.28, Аноним (-), 22:49, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Перебрать всех известных клиентов в цикле и не загромождать API ядра.

    А если список клиентов заранее неизвестен?
    Примеры: подписки на события типа "смена часового пояса" (важно всем программам, работающим с локальным временем), "поднятие сетевого интерфейса" и т.д.

     
     
  • 5.38, Аноним (-), 00:03, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > А если список клиентов заранее неизвестен?

    Все там известно. "Если пир не предоставил дескриптор, то сообщение заданному узлу отправить невозможно." Т.е. отправитель должен знать кому он отправляет сообщения, но можно отправить всем сразу одним вызовом.

    ИМХО, мультикаст на уровне ядра может оптимизировать только количество переключений контекста "ядро<->юзерспейс" (т.к. цикл будет гонять ядро в одном системном вызове). Может быть, получится снизить количество копирований мультикаст-сообщения (не уверен, тут надо глубоко вникать). Для сообщений уровня "вставлена флешка" и "переход на питание от батареи" пофиг на оверхед.

     
     
  • 6.40, Аноним (-), 01:27, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Все там известно. "Если пир не предоставил дескриптор, то сообщение заданному узлу
    > отправить невозможно." Т.е. отправитель должен знать кому он отправляет сообщения, но
    > можно отправить всем сразу одним вызовом.

    Каждому по отдельности? It's super effective!

    // Из-за таких "эффективных программистов" вроде бы простые приложения еле ворочаются на современной технике, хотя по функциональности они недалеко ушли от софта времен 80386.

     
     
  • 7.46, Аноним (-), 02:28, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    О, сразу про "эффективных программистов" вспомнил.

    Ничего, что Линус в прошлый раз завернул эту компашку с резолюцией "у вас неэффективное гoвнo в юзерспейсе, перепишите там, потом приходите в ядро"?

     
     
  • 8.81, Аноним (-), 01:27, 31/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    А если про них не вспоминать - так dbus уже есть Да и binder с другой стороны ... текст свёрнут, показать
     
  • 7.52, Аноним (-), 09:00, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Каждому по отдельности? It's super effective!

    Не придирайся. "броадкаст неизвестному количеству клиентов" вообще плохо сочетается с требованием "гарантированной доставки". Поэтому циклы придется гонять в любом случае, вопрос только кому именно...

     
     
  • 8.67, Elhana (ok), 17:51, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Так судя по их презентации оно и отправляет этот мультикаст именно каждому пир... текст свёрнут, показать
     
  • 4.33, Аноним (-), 23:10, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    есть netlink который умеет и multicast тоже.
     
     
  • 5.43, Аноним (-), 01:36, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > есть netlink который умеет и multicast тоже.

    А можно пример проги, которая использует netlink и запускается не от рута, а от юзера?

     
     
  • 6.62, Аноним (-), 14:45, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> есть netlink который умеет и multicast тоже.
    > А можно пример проги, которая использует netlink и запускается не от рута,
    > а от юзера?

    iproute2

     
     
  • 7.65, Аноним (-), 16:00, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    мультикаст в netlink можно только от рута использовать
     
  • 6.82, Аноним (-), 01:28, 31/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > А можно пример проги, которая использует netlink и запускается не от рута, а от юзера?

    iw например.

     

  • 1.26, freehck (ok), 22:20, 27/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Мне казалось, что этой новости пара месяцев уже. Где-то с сентября же разговоры идут. :)
     
     
  • 2.27, freehck (ok), 22:29, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ну точно: 17 августа.
    http://lwn.net/Articles/697191/
     
  • 2.32, Аноним (-), 22:59, 27/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Мне казалось, что этой новости пара месяцев уже. Где-то с сентября же
    > разговоры идут. :)

    Насколько я помню, еще с начала года.

     
     
  • 3.56, Andrey Mitrofanov (?), 10:04, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> Мне казалось, что этой новости пара месяцев уже. Где-то с сентября же

    Эта новость наверху -- отдельная невиданная доселе веха, "новый" код явлен Миру. Ларабель Похорониксович празднует. Ждём длиииинной череды постов про "Кернел N+0.1: BUS1 снова-опять-почему-то-ждём-скучаем не в мейнлайне" от задорного парня Микаэля.

    >> разговоры идут. :)
    > Насколько я помню, еще с начала года.

    Сначала их долго выпинывали, наконец до них дошло... Но не совсем: они почему-то решили, что нарисовать с нуля и сменить вывеску "должно всё изменить"ТМ. Придумали название и пошли писать код.


    09.12.2015 [B]BUS1:[/B] A New Linux Kernel IPC Bus Being Made By Systemd Developers
      http://www.phoronix.com/scan.php?page=news_item&px=BUS1-In-Development

    09.11.2015 KDBUS Is Indeed Going [B]Back To The Drawing Board[/B]
      http://www.phoronix.com/scan.php?page=news_item&px=KDBUS-Back-To-Design

    30.10.2015 KDBUS Is Being [B]Removed[/B] From Fedora, Could Be A While Before Being Mainlined
      http://www.phoronix.com/scan.php?page=news_item&px=Fedora-Drops-KDBUS

    10.07.2015 The NSA Is Looking At Systemd's KDBUS
      http://www.phoronix.com/scan.php?page=news_item&px=NSA-KDBUS-Credentials

     
     
  • 4.59, freehck (ok), 11:33, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > A New Linux Kernel IPC Bus Being Made By Systemd Developers

    Погодите, так это те же самые ребята? Мда. Ну, значит дело опять тухляк.

     
     
  • 5.83, Аноним (-), 01:32, 31/10/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Погодите, так это те же самые ребята? Мда. Ну, значит дело опять тухляк.

    Да, эти ребята не только сделают шину но ей еще и софт сможет реально пользоваться. А не как у других ребят - какая-то номинальная куита для галочки, которой может и не быть в 80% систем, так что вы там держитесь и кодьте покамест fallback сами. Что вам, впадлу самому системную шину реализовать как умеете?

     

  • 1.36, Аноним (-), 23:54, 27/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    самое интересное: надеюсь протокол - текстовый?
     
     
  • 2.47, Аноним (-), 02:29, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Каанешно! :-)

    http://gentooexperimental.org/~patrick/weblog/archives/2014-11.html#e2014-11-

     

  • 1.37, anonymous (??), 23:58, 27/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ну надеюсь на этот раз Торвальдс взорвется и даст уже оценку поделию пОТТЕРА!

    а в идеале за недельку сам напишет человеческий аналог который везде продвинут

     
     
  • 2.45, Аноним (-), 01:43, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > ну надеюсь на этот раз Торвальдс взорвется и даст уже оценку пoделию пОТТЕРА!

    Он уже это сделал
    > I don't personally mind systemd, and in fact my main desktop and laptop both run it

    © Linus


     
     
  • 3.48, Аноним (-), 03:04, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Это он дипломатично увернулся от неудобного вопроса. Представь, каково это: с одной стороны, тебе надо беречь и поддерживать репутацию справедливого и объективного лидера, а с другой - ты акционер Red Hat. И как вот выкручиваться от таких вопросов ребром?
     
     
  • 4.73, Аноним (-), 01:15, 29/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Это он дипломатично увернулся от неудобного вопроса. Представь, каково это: с одной
    > стороны, тебе надо беречь и поддерживать репутацию справедливого и объективного лидера,
    > а с другой - ты акционер Red Hat. И как вот
    > выкручиваться от таких вопросов ребром?

    крупный акционер имеет веский голос в принятии решений или нет?
    сомневаюсь, что RedHat владеют полностью отмороженные товарищи не понимающие куда все движется
    значит, его все и так устраивает

     
     
  • 5.74, Аноним (-), 01:43, 29/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Похоже, что он вовсе не такой крупный, как вам кажется.
    https://investors.redhat.com/stock-information/ownership-profile
    В любом случае, дело-то не в том, крупный ли он акционер, а в том, что он медийная личность, и неаккуратно проболтавшись о технической стороне вопроса он может сильно нагреть самого себя прежде всего.

    >сомневаюсь, что RedHat владеют полностью отмороженные товарищи не понимающие куда все движется

    Они-то как раз все понимают. Леня им сотворил гигантский зонд, который по сути вендорлочит вообще все линукс-коммьюнити на ред хате. А раз оно формально free software, то вроде бы и не придерешься.

     
  • 4.84, Аноним (-), 01:36, 31/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Это он дипломатично увернулся от неудобного вопроса.

    Это скорее хейтеры демонстрируют wishful thinking во весь рост. А так Торвальдс может без обиняков заявить Каю Сиверсу (или любому другому) что тот full of sh*t если тот косячит. С предложением вытряхнуть sh*t и прийти в адекват. А кто сказал что Сиверс или там кто еще на это не способны? Судя по кардинальной переделке сабжа - вполне себе.

     
  • 2.54, Andrey Mitrofanov (?), 09:20, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > ну надеюсь на этот раз Торвальдс взорвется и даст уже оценку поделию
    > пОТТЕРА!
    > а в идеале за недельку сам напишет человеческий аналог который везде продвинут

    Ты всё перепутал: там, когда было переписывание за недельку, Линусу не давали пользоать, но дали "списать", а тут всё наоборот: пользование пхают во все дыры, а от "списывания" он "диполоматично уварачивается"ц, аотому как нет там :/ предмета для творческой кражи.

    Совсем не похоже.

     

  • 1.53, darkshvein (ok), 09:15, 28/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    попетросяню. systemdBus1 ?
     
     
  • 2.58, Andrey Mitrofanov (?), 10:22, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > попетросяню. systemdBus1 ?

    Нет, s-d-libkerneld. Всё остальное ядро будет пришлёпкой сбоку к Великому Поделию. Щупальца №2, ну, бишь bus1, запускается, запускается щупальца... в ядро...

     

  • 1.55, Нанобот (ok), 09:48, 28/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >сокрытие информации

    ст 237 УК РФ

     
  • 1.94, Аноним (-), 20:58, 13/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ох, жарко то как, аж криокамера у меня поломалась!

    Ну заменят допустим kdbus на bus1, но самый обычный DBus никуда не денется-то... если вдруг даже на десктопе и нужен будет DBus с ядерной скоростью, то напишут для отдельных просителей и ответчиков обёртку типа apulse и xwayland, и libdbus для LD_PRELOAD

    Совместимость древнего и заброшенного поломается не сильно, зато можно будет сочетать безопасность со скоростью.

     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру