>Куда более вероятный сценарий: звук работает бОльшую часть времени, в какой-то момент
>драйвер вываливается и тут же перезапускается, причем пользователь может этого даже
>не заметить.

Таких драйверов не должно быть ни в микроядерной ось ни в монолитной.

>>Монолит : В самом кривом случае кернел-паник (что не смертельно, ибо всё
>>останется живым после рестарта) итог 1 - звука нет.
>
>Если Вы считаете kernel panic "несмертельным", то наш разговор продолжать бессмысленно, ибо
>основная цель микроядра - избежать этого сценария. Кроме того, отчего Вы
>так уверены, что все "останется живым после рестарта" ? А если
>в драйвере файловой системы будет ошибка, которая приведет к непоправимой порче?

Спорить об ошибках драйверов FS, к примеру журналируемых, так же бессмысленно как и про "несмертельность" кернел-паник. Всё же это эталон качества и неотъемлемая часть монолита.
Да и не стабильный драйвер FS в микроядре создаст такую же предпосылку к потере данных.

>>Производительность будем сравнивать? Давайте хотя бы приблизительно:
>>
>>1. Микроядро. Драйвер не имеет прямого доступа к обороудованию, обращается за этим
>>к микроядру. Переключение контекста 1. Латентность самого микроядра 2.
>
>Во первых, драйвер, хоть и не имеет прямого доступа к оборудованию, зато
>имеет к физической памяти, если устройство работает через DMA.

Периодически всё же нужны порты ввода/вывода, да и окна адресного пространства менять. А прерывания от оборудования в существующей архитектуре (IBM PC) не могут обработаны напрямую за пределом RING0. Да и специфика узка - рассматриваем ведь только IBM PC. А как там на маках? Как на Sparc?

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

Данные ходят сложнее чем память/устройство. Например нужно выдеопоток отправить в сеть, это заставит мокроядро посильно участвовать в координации процесса. По крайней мере в теории. Если честно, не в курсе как это сделано в MINIX.

>[оверквотинг удален]
>этих потоков к одним процессорам с целью избежать перезагрузок кэша, поллинг,
>контроль за частотой прерываний и включением/выключением поллинга, и прочие прелести.
>
>>Интересно будет посмотреть на производительность когда USB корень задолбит микроядро >запросами от мыши и клавиатуры.
>
>Если Вы думаете, что проблем с этим нет у монолита, то Вы
>ошибаетесь. Любое немаскированное прерывание влечет за собой как минимум два переключения
>контекста - на поток, обрабатывающий прерывание, и обратно. Поэтому проблемы тоже
>есть, и решаются они точно так же, как и в случае
>микроядра.

У I386 при разных RING переключаемых контекстов требуется несколько больше тактов для применения атрибутов безопасности контекста. Но это проблема I386, хотя может в CORE этот момент оптимизировали...
Но тут уже надо в цифрах латентность сравнивать да и количество переключений...

Но это всё мелочи, ибо пока главная проблема MINIX это оборудование...