Kdbus — межпроцессный обмен сообщениями на уровне ядра

Это, конечно, супермегаафигенно. Но не будет ли это попыткой из монолита сделать микроядро?

А не наоборот, разве? Сделает ядро ещё более монолитным?

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

ИМХО.

make menuconfig никто не отбирал.

годная идея для linux 2.8.

Просто желаю достойной реализации отличной идеи.

А ядро не будет паниковать из-за всяких глючных программ?

Это совсем-совсем не то.

Такая паника была бы равноценна тому, что падает то же микроядро от того, что какая-то программа посылает сообщения. При должных проверках на переполнения паник не возникнет.

поначалу - будет обязательно.

>микроядро?

Как-бы dbus это приблуда прикладных, и в основном gui прог. В микроядре же ipc для ядерных тредов.

А как же микроядерные сервисы на пользовательском уровне должны обмениваться сообщениями?

Ну хз, подходит ли оно для такого.

Не там они узкие места ищут и оптимизацию проводят. Совсем не там.

На опеннете писали, что на синтетических тестах прирост производительности в два раза, на реальных – на четверть. Я не впечатлён.

Идея хороша, но для подобной задачи у dbus'а вроде бы сильный оверхед. Он вроде бы xml'м обменивается, нет?

Не там ты троллишь, совсем не там.

Ну, если xml будет на уровне ядра, то нафик такое поделие.

> Пожелаем удачи проекту, а также включения в «ванильное» ядро и большинство дистрибутивов.

нет.. спасибо.. я пожелаю обратного :-)

Давно бы так.

Линус пошлет авторов проекта на йух. И правильно сделает. Нечего
тащить в ядро всякие абстракции - только минимально необходимое,
прозрачное. И так, некоторые ошибки годами ищут. Не стоит усложнять.

>Это, конечно, супермегаафигенно

Вы так говорите, как будто dbus основная причина тормозов в линуксе.

Здравствуй, Linux Максимальная, что ли?

сам то понял что сказал?

> При должных проверках на переполнения паник не возникнет.

При должнык проверках защита памяти не нужна. А еще при должных проверках софт не глючит.

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

> А как же микроядерные сервисы на пользовательском уровне должны обмениваться сообщениями?

перемапливание памяти MMU + copy on write

При должнык проверках защита памяти не нужна. А еще при должных проверках софт не глючит.

Как бы вот.

как бы вот.

Вроде да, xml. Для уровня ядра мне кажется это слишком (в ядрах не разбираюсь). С другой стороны если это будет завёрнуто в libdbus, то на уровне ядра вполне может ходить и не xml.

да нету там xml. откуда вы это вообще взяли?

Так согласен же.

:) из конфигов наверное.

по сабжу, не нужен сабж. Там прироста даже 25 процентов не было. А много ли юзкейсов когда узким местом является dbus. Empathy, у которой все на dbus imho более частный случай, чем закономерность.

25% - это на самом деле офигенный прирост... там некоторые ради 5-7% готовы улучшать и минимизировать, а тут целых 25...

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

Разве обычную очередь сообщений в Linux уже отменили?

*facepalm*

реалии жизни плавно так, незаметно приближают нас к глубокому осознанию правоты Таненбаума... :D

очередное решето

Прчием тут микроядро-то, объясните? Микроядро — это когда в ядро тащат всё подряд, что ли?

+1, нормальные люди уже давно всякую хрень из ядра в юзерспейс вытаскивают, а какие-то извращенцы пытаются вместо этого натаскать в ядро новой хрени.

сначала про kde подумал. KDE - графический рабочий стол внутри ядра для увеличения быстродействия.

Например в каких массовых платформах это делают?

не понимаю - что все так переполошились? Доведут (если не забросят) сабж до того, что бы его включили (официально) в ядро - посмотрим.

зы. во всяком случае - menuconfig никто еще не отменял...

Например, был devfs — стал udev. Была куча глючных экспериментальных драйверов фс — стал fuse.

>>Разве обычную очередь сообщений в Linux уже отменили?

Про то и речь. Ядро как бы один процесс. Юзерспейс программа -другой. Области памяти разные, в общем случае недоступные друг другу. Защита реализована в железе на различных архитектурах. В стандартном варианте надо сохранить кой какие регистры, да скопировать одну область памяти в другую. Последняя операция прямо пропорциональна объему передаваемых данных. В 64 битных интелях за такт можно передать что-то около 128 бит данных, при нынешних объемах не так много. Идея, насколько понял, в достаточно безопасной реализации «общей памяти», чтобы избежать процесса копирования. В общем - штука интересная.

Желаю проекту поскорее сдохнуть, чтобы не захламлять ядро.

А для меня это было ожидаемое событие - т.е. я давно думал, что к этому идёт. Правда, не так скоро. Хотя, как черновик - наверное, время.

For the unaware, DBus already allows private buses that allow direct peer-to-peer communication. AFAIR it was introduced exactly due Telepathy’s heavy weight usage of DBus to talk to peers. So it’s a moot point to suggest that, it’s already there and being used.

В целях увеличения производительности компьютера представлен проект Kdbus

Не путать с kdbus 0.8.6, который является просмотрщиком D-BUS в KDE, как kdcop для DCOP.

Действительно непонятно, чего все переполошились?

Ну будет ещё один способ обмена - на этот раз сообщениями только в конкретном формате. Ну и что с того то?
Все системы в том или ином виде поддерживают обмен данными.
Если не подходят текущие способы обмена информацией - делают новые. Вот и всё!

Идею в принципе - поддерживаю. Посмотрим на реализацию.

Kernel Desktop Environment?