> Сложность отладки, Было актуально ...цать лет назад. С виртуализаторами - можно ковырять вдоль и поперек. Даже снапшотов с образами оперативной памяти налепить и колупать их потом в свое удовольствие. А еще там KDB есть к тому же, так что если ядро не полностью околело, можно его само собой же и отлаживать :)
> повышенная опасность ошибок в коде.
Вот это есть. Ну так и отношение там к коду лучше чем у абы каких быдлокодеров все-таки.
> Тем кто подписался на сообщение. Так для рассылки такого ядерные скорости совершенно
> не нужны. Сообщения о смене питания можно вообще через минуту обрабатывать,
Через минуту - не пойдет. За минуту юзер может сделать кучу действий связанных с питанием. Кроме того, ядру все эти события просто виднее всего по его природе. Ну, работает ядро и его модули с интеллектуальным чипом менеджера питания, висящим на I2C шине, например. Логично что если чип информирует нас о чем-то - удобнее всего было бы чтобы ядро отброадкастило от него эту информацию всем заинтересованным подписчикам. А зачем там туева хуча побочных прослоек? Так пожалуй даже менее надежно станет - чем больше звеньев в цепи, тем вероятнее что что-нибудь обломается и сглючит.
> никто не помрёт. Это, конечно, крайний случай, но такая шина уведомлений
> не должена гонять большой трафик.
Для универсальной шины заранее не известно какой именно там будет траффик и по какому поводу. Значит оно должно быть способно на многое. Иначе потом юзеры начнут удивляться - что за нафиг - процессор грузится непонятно чем, батарей садится на 2 часа раньше чем должна! Отстой эта ваша операционка!
> Поэтому тут достаточно программы пользовательского режима, гоняемой, видимо,
> даже не из-под root'а, а, скажем, пользователя dbus из группы dbus.
Так оно сейчас как-то так и есть, но мне не совсем понятно на основании чего ядро должно быть обделено на возможности броадкаста и получения сообщений.
