Микроядро и нити монолитного ядра

не всегда. //thread

Если вдруг, что, то главный поток ядра всегда сможет перезагрузить нить - драйвер.

судя по Linux-ядру(как на практике, так и по книгам) - таки не всегда. Попробуй-ка принудительно выгрузить багнутый модуль с ключом -f. Самое милое что ты получишь - процесс зависнет. В худшем случае - oops или паника...

судя по Linux-ядру(как на практике, так и по книгам) - таки не всегда. Попробуй-ка принудительно выгрузить багнутый модуль с ключом -f. Самое милое что ты получишь - процесс зависнет. В худшем случае - oops или паника...

Ну это проблема именно такой реализации монолитной архитектуры, а не монолитной архитектуры в целом...

Драйвер может сделать *((int*)12345678) = 9012345; и чего-нибудь испортить. Например в другом драйвере, или в другой части ядра. В микроядерной архитектуре такого происходить не должно.

У монолитного ядра адресное пространство общее

Проблема не в том, что нельзя прибить нить со сбойным драйвером, а то, что при сбое драйвер может легко разнести пол-ядра и убийство нити уже не предотвратит Kernel Panic.

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