> Это довольно редкий тип событий и без особого трафика.На самом деле - как повезет.
>> Обмен между программами в изолированных окружениях информацией в аккуратном и контролируемом виде.
> Corba уже есть.
Насколько я понимаю - все реализации получались столь переросточными что ими никто кроме махровейшей ынтырпрайзятины просто не рискует пользоваьтся. Собственно, где оно в мелком, легком и культурном виде, простом для использования софтом и достаточно легким чтобы даже ядро могло в этом принять участие?
> Есть же вроде syslog, в котором вывод настраивается.
Как бы нет стандартного метода кинуть сообщение, а там пусть разные получители логгят как хотят. Сислог - частный случай. В результате появляются всякие там systemd и их супер-пупер-логгеры как ответ на все вопросы жизни и всего-всего. Ну то-есть есть системный вызов, но он не подразумевает в своем дизайне неопределенную группу таргетов, которые заинтересованы в получении логгинга. Изящнее было бы пулять логгинг в шину а там пусть все заинтересованные подписываются на это, если им надо, и логгят как им там удобнее. Кому нравится - сислог, кому нравится - системдэшный логгер, кому нравится - еще что-нибудь. Смотрелось бы вполне логично вроде. И заодно заткнуло бы вопли насчет того какой логгер расово верный. Они бы просто стали все абсолютно равноправными, сосуществующими совместно out of the box, etc. Вся эпопея просто мигом закончилась бы. И устроило бы и олдскульщиков с сислогом, и аваннгардистов с systemd и еще 100500 граждан с специфичными потребностями. А кернел мог бы например предоставить сервис логгинга в оперативу для девайсов с глухим readonly в ФС, благо он наполовину умеет это. А так умел бы целиком, включая не только свой крешдамп но и сообщения сервисов на момент до краха.
> Если не хватает - для большого трафика есть pipe, sockets.
Вот только
1) Форматы обмена никак не стандартизированы. Поэтому или софт знает друг друга явно, или возникает уйма головняка и костылестроения. В самых типовых операциях. Казалось бы простая задачка, сделать несколько получателей системных логов - превращается в целый отдельный головняк.
2) По большому счету эти механизмы не предназначены для броадкаста заведомо неизвестной группе получателей.
3) Собственно шины по большому счету являются логичным развитием идеи. Решая проблемы 1) и 2).
> Вопрос - как часто? Если делать общесистемную шину, держащую большую нагрузку, к
> ней придётся прикрутить:
> 1. Планировщик.
> 2. Приоритетность сообщений.
> 3. Разбиение сообщений на пакеты (для больших сообщений).
> 4. Сложную систему блокировок.
> 5. Мультипроцессорность.
Как ни странно, даже самый обычный TCP/IP стек в любой нормальной операционке обладает всеми этими свойствами, живет в ядре, имеет около нуля опасных багов и почему-то никаких проблем по этому поводу никто не испытывает. Получается что сделать такое не просто можно, но и делается на регулярной основе.
> Если учитывать сетевые транспорты, всё ещё больше усложняется, т.к. скорость
> транспортов будет отличаться на порядки.
Да, вот это уже хитрее, но я думаю что ремотный доступ по шине - сам по себе источник ремотно эксплойтабельных дыр. Как максимум таким должен заниматься какой-то отдельный бридж, берущий на себя подобные вопросы. Скорее всего уже в юзерспейсе.
> Поэтому значительно проще ограничить область применения редкими и маленькими сообщениями,
Да, а еще можно упразднить TCP и оставить только какой-нибудь UDP-lite. И маршрутизацию нафиг. И планировщики и приоритеты. Вообще, нехай только в пределах 1 сегмента работает, а лучше - только локалхоста. Тогда еще и драйвера сетевух можно выбросить. Зато насколько сетевой стек упростится сразу.
> открывая каналы и соединения там, где нужна передача больших данных и
> в близком к реальному времени режиме.
И не пользуясь преимуществами шины. Вот скажите, кто как не кернел может очень эффективно реализовать мультикаст? Вплоть до zero copy.
