> Большей стабильности ядра, Проблема просто перекочует в другое место. Знаете, тот же линуксный кернел можно юзать даже в виде первого -rc, как правило ничего не падает. А основная масса сбоев - в логике работы с периферией. Ядро при этом обычно не валится, но и периферия не работает. Фатальность очень зависит от периферии. Без usb-хаба накрайняк можно пережить. А вот если видео например отпадет - это уже ой, извините.
Вон у AMDшников например (нуачо, большой и сложный драйвер, где отладка актуальна) в процессе отладки драйвера основная проблема - вовсе не крахи и не взвисы драйвера режима ядра, отнюдь. Как раз драйвер обычно стабилен, несмотря на навороченность. А взвисы - у GPU, с его стороны. А дальше драйвер с переменным успехом пытается оживить пациента :). Как-то так вышло что GPU довольно чувствительны к кормлению г@вном, да еще имеют свое мнение о том что есть г@вно (лулзовых ERRATA всех мастей там есть). При этом не принципиально как в GPU попали глючные команды, GPU вообще не интересует, ядро это сгенерило или юзермод облажался. GPU встанет колом одинаково. Основные предъявы при этом кстати user-mode компонентам. Ядро делает минимум и там как раз все стабильно. Зато какой-нибудь LLVM запросто может сгенерить некорректный код, а большинство GPU не имеет средств аппаратного детектирования кривого кода и по этому поводу просто встают в позу, получив некорректный набор команд.
Про то что оно может прострелить череп системе сделав DMA не туда - я вообще молчу. Работает оно так, что DMA - везде, тотально. Нужные скорости I/O без DMA вообще не получаются. Новое железо умеет IOMMU, конечно, но это довольно опциональный компонент и свойство железа. Никакой kernel vs user никак не может ограничить железку в том куда она через DMA данные пуляет. А если железка вгрузит порцию данных в то место памяти где ядро лежало - ядро умрет независимо от того микро оно или макро.
> большей лёгкости отладки драйверов
Пока что я вижу толпу ядерщиков, которые успешно кодят и отлаживают монолиты/гибриды и .... микроядерные ОС без драйверов, на секундочку.
#include <trollface.jpg>
> за счёт несколько меньшей производительности.
Пока вы разводили тут бла-бла, в линуксе сделали пару приблуд для упрощения всякого драйверообразного кастома в юзерспейсе. Спросите уже у гугли про UIO и VFIO (ну и libusb до кучи можно). Вот только используется это не столько для драйверов, сколько для кастомной работы из программ с экзотичным оборудованием со всякими спецтребованиями, т.е. всякий служебный/сервисный софт. Писать драйвер ядра для всякой экзотики, например, драйвер boot ROM проца висящего на USB как device - может быть не оправданно, если этот режим использует 1-2 программы на планете и это врядли изменится. В упомянутом примере, например, обычному софту, который не прошиватор - режим ROM recovery у девайса ни к чему, о нем надо знать явно и уметь аплоадить данные по кастомному протоколу, иначе этот режим не для вас. В этом случае проще подергать из юзермода libusb, чем писать ядерный драйвер, нужный "1 раз в жизни, 1 программе". А вот для регулярного использования софтом ядерный драйвер будет лучше.
> Это, собственно, можно видеть на примере ntfs-3g, где драйвер аналогичный
> микроядерному (т.е. ntfs-3g fuse) был выпущен намного раньше, чем драйвер режима ядра.
И жpeт проц в полку при записи на диск, упираясь как правило в проц, а не диск. Спасибо, конечно, но такие файловые системы - не, ну 1 раз в жизни прочитать виндовый диск и забыть о нем навсегда - катит. А вот повседневно юзать... я вот почему-то переформатил в свое время в EXT3(нынче EXT4) и XFS. С нормальными ядерными модулями. Стало в разы быстрее и нагрузка на проц упала раз в 20. Грызть кактусы на регулярной основе... а знаете, переключение контекстов крупным оптом клинило процы что 20 лет назад, что сейчас.
