api dbus - это трындец и ужас

я хоть и осилил, но мне не понравилось. сраный dcop и то был лучше

че за qnx? это та штука на дискете с убогин браузером и звонилкой диалап. не, не слышал:)

Чем им так не нравится dbus?

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

сама идея мне нравится, если это будет не dbus в том виде как сейчас

надо было микроядерную архитектуру делать

как вы задолбали. слишком много оверхеда, etc

как дядька Таненбаум говорил

он уже сам отрекся от своих слов

unix сокеты могут мультикаст? а вообще чего-то захотели более высокоуровнего и message-orientated(как в nt)

Ценность вашего комментария выдает в вас принадлежность к большому начальству.

кто-нибудь может внятно объяснить зачем это в ядре?

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

ммм... а добавить мультикаст к Unix domain socket-ам не было бы достаточно?

Во-первых, не очень представляю как это сделать (дублировать считывание каждого байта для каждого читающего процесса или что?), ну и плюс еще сериализация (собственно, она и разделяет на «сообщения») и «слабое» связывание (ты себе подписываешься на событие, не важно, существует такой сокет или нет впринципе).

Кроха-Картман ;)

ммм... а добавить мультикаст к Unix domain socket-ам не было бы достаточно?

Оно примерно так и есть:

AF_BUS is based upon AF_UNIX but extended for multicast operation and removes stream operation

Только сокеты — это не всё. D-Bus ещё интересен тем, что для его работы не обязательно держать запущенное серверное приложение, dbus-daemon может сам его запустить, когда к нему будет обращение. Такой себе аналог inetd. И сделать секурно такую штуку в ядре не выйдет.

следующим шагом будет интеграция systemd?

Ну то есть «reliable multicast and point-to-point messaging system for the kernel», зачем она нужна ядру-то?

Чтобы передавать одно сообщение нескольким подписчикам. Скажем, я пишу приложение, которое при подключении по блутузу будет спрашивать у юзера пин. Или я пишу докпанель и хочу, чтобы при переключении десктопа на ней менялся фон. Как она узнает о переключении десктопа?

Нужен универсальный механизм, который позволит просигналить о событии нескольким программам. Сейчас этим механизмом является dbus. Запусти qdbusviewer и посмотри, там много интересного.

Можно ли Linux kernel обратить в микроядро?

бгг

anonymous не true!

Странный какой-то anonymous попался - читающий. Кроме того, ещё и понимающий, ещё и нормально объясняющий. Странно, но могу только +1 сказать :).

Кроме этого, такая штука (kernel-level message bus) крайне нужна для полной интеграции Android kernel с codebase vanilla kernel: http://elinux.org/Android_Binder

Только сокеты — это не всё. D-Bus ещё интересен тем, что для его работы не обязательно держать запущенное серверное приложение, dbus-daemon может сам его запустить, когда к нему будет обращение. Такой себе аналог inetd. И сделать секурно такую штуку в ядре не выйдет.

я таки надеюсь, что этого демона они вынесут в юзерспейс... правда велика вероятность, что он станет частью systemd, потому что «он запускает сервисы», да!

но даже если и так, то при желании можно будет этого демона отвязать от systemd

неа. еще нужен стандарт на ФОРМАТ данных. в socket можно пихать любые данные как левая нога захотела, а в DBus только стандартными пакетами.

1. и что? libdbus могла бы из любых данных делать стандартные пакеты (и обратно), не?

2. в сокет, афайк, можно пихать не только данные, но и дескриптор; тут можно было бы добавить возможность пихать пакеты

1. и что? libdbus могла бы из любых данных делать стандартные пакеты (и обратно), не?

libdbus гарантирует, что все, что через нее прошло, является стандартным пакетом данных. Или дает ошибку на этапе валидации и ИСТОЧНИК данных получает ошибку. Кривые данные не попадают на шину.

2. в сокет, афайк, можно пихать не только данные, но и дескриптор; тут можно было бы добавить возможность пихать пакеты.

API сокетов не имеет защиты от кривых данных. Никакой. Потому ошибку получит ПРИЕМНИК. Т.е. ошибка вылезет не в месте возникновения (источнике), а в месте обработки. Что сеть плохо и печаль.

ну, наконец-то. ждём-с...