ядрото иска udev, udev иска systemd за да работи.
Това не е вярно. Предполагам визираш kdbus, kdbus не изисква udev за да работи. kdbus е kernel-базиран message bus, нещо като dbus, само че реализиран в ядрото. dbus е много хубаво нещо като идея, но като реализация е кошмарно. Човек може да преглътне xml простотиите, но това има много проблеми - свързани с performance, някои са архитектурни. Навремето имахме един голям проект, който използваше dbus изцяло като IPC механизъм между всичките наши софтуери, които вървят на една embedded платформа. В началото всичко беше прекрасно, но много скоро се стигна до големите проблеми. Хората започнаха да блъскат какво ли не върху dbus-а, включително стигнаха до свинщината да мятат картинки и аудио. И всичко буквално клекна. Идваха големи глави, оптимизираха dbus (има добре известни неща които могат да се направят и без да си голяма глава, но друго е когато голямата глава го направи). Това не помогна особено, нещата клекнаха отново много скоро. И се почна с проучване на варианти за търкаляне на част от нещата върху shared memory и отебаване на dbus за прилична част от нещата - нито throughput-а му беше като хората, нито латентността в случая в който това имаше значение, беше нормална и предсказуема. И проблемите са архитектурни - има 50 context switch-вания за един RPC call, unicast комуникацията не е много истинска и минава през dbus сървъра, който като има да търкаля някоя голяма свинщина, всички останали чакат.
Та kdbus ако адресира тези проблеми, ще реши доста проблеми поради което съм с две ръце "за". Ако е реализирано в ядрото, една много прилична част от проблемите ще могат да се решат, главно проблема с многото превключвания на контексти. Но както и да е, просто не виждам по какъв начин kdbus би зависил от udev.
Що се отнася до това обвързване на udev със systemd, не съм запознат с драмата и не мога да коментирам.
Форка ще е много сложен, ако започнат да интегрират части от udev в ядрото което е противно на самата изначална идея за userspace /dev.
Това пък защо?
Не знам за кои clients говорят но от тази приказка разбирам, че за да се обърнеш към udev да ти свърши някаква работа трябва да минеш не през libudev, а директно към ядрото.
Предполагам са заменили ползването на dbus с kdbus. Което може и да не е толкова лоша идея.
Може би gat3ay има по-добра представа за това, но излиза, че два юзърспейс процеса ще си плямпат през ядрото, а не директно. Явно са намислили да депрекират dbus. Бе пълна каша се заформя.
Два юзърспейс процеса винаги си говорят през ядрото, защото има изолация на адресни пространства и не биха имали друг механизъм да си говорят, освен механизмите които ядрото им предоставя. Всякаква форма на IPC - шерната памет, пайпове, сокети, дори писането в общ файл, всичко това минава през ядрото. Шернатата памет е малко по-специален случай, защото не се налага да минаваш през ядрото всеки път когато четеш или пишеш в нея. Но дори и тя изисква намесата на ядрото, за да се случи. Просто така работи всяка нормална многозадачна операционна система, не е нещо линукс-специфично.