>если в линухе из за ошибки в драйвере крешится кернель но в
>миниксе этого нет так как драйвера на ходятся в узер спейсе
>миниксу достаточно перезагрузить драйвер и всё Я видел функциональность этих драйверов и то, как они выполняют привилегированные инструкции. Открыл /dev/mem - получил привилегии записи в порты. Так это было в minix2? Это даже не хак.
А как DMA делается из юзерспейса? DMA с MMU процессора не дружит ;] Я увижу каркас драйвера для фреймбуфера и картинки взаимодействия/восстановления после падения подсистем в minix? Или вдруг умершей файловой системы?
>это одно из превосходящих линукс отличий а их много если детально покапаться
Да да, я понял, только я пока ни 1 отличия не заметил. Драйвер (допустим файловой системы) магическим образом восстановит устройство, файловую систему и все сервисы, которые он повесил не ответив на сообщения (не первый раз пишу!). Что за бред? Вы меня слушаете вообще? Я вам привел конкретные примеры.
Все приведенные в таблице преимущества "абсолютно" верны и высосаны из пальца. Можно сравнить вызов функции с вызовом COM метода и нарисовать _точно_ такую-же таблицу. А потом еще и добавить что применив ухищрения можно свести COM выозов к вызову функции и наоборот (ну чуть более затратным). Вам приходилось работать с разветвленной структурой COM объектов? Как ощущения? :]
Единственное, с чем я могу согласиться - это то, что core уровень сетевой подсистемы в linux немного хрупок. Он может вызывать и часто вызывает невосстановимую панику ядра в результате ошибок. Это компромиссное решение. Часть сетевой подсистемы торчит прямо в обработчике прерываний (из-за вопросов производительности). Естественно, особо не повосстанавливаешься. Лично для меня это проблем не вызывает. Возникнут - будет висеть отдельный ядерный поток.
>и плюс Танненбаум давно уже не занимается миниксом а количество энтузиастов конечноже
>на много меньше чем разработчиков ядра линукса
Очень жаль, что не хватает рук для раздутия этой малюсенькой системы до масштабов неуправляемого монстра (типичного для такой "структуры"). Можно было бы посравнивать.
>вы говорите про реализацию виртуальной памяти зачем она нужна если есть кернель
>апи непосредственного управления паматью ? зачем ешё одна дополнительная прослойка?
Про SWAP слышали? Про NUMA? Про изоляцию процессов на аппаратном уровне? Толку от микроядра, если процессор не защищает адресные пространства сервисов? Это же похерит всю вашу идеологию, единственный (не очень)очевидный плюс микроядра ;]. Пользуясь API вообще пофиг, _как_ он реализован.
>ядро
>должно заниматься строго конкретными заданиями а то что юзеру нужен блутуз
>пусть он напишет драйвер под него и всё и не надо
>мне отписывать Танненбауману чтобы он добавил мой код в ядро системы
>))) и ждать его одобрения как это делается с линуксом
Ага, ясно. Только в linux он есть, а в minix нет и, видать, не будет.
>Как по вашему линукс можно назвать RTOS ????
На какой архитектуре? :]
Это _совсем_ другой холивар. Можно (правда, тут всё страшно зависит от задачи). Более того: монолит реалтаймом сделать не сложнее, чем стадо процессов. Про l4linux и -rt ветки, думаю, слышали. Я не зря сразу спросил, стоит ли у вас микроядро на десктопе. На нем элементы реалтайма куда важнее, чем какого-то сетевого сервера.
Опять же заранее соглашусь, что систему "без мяса" (читать: без функциональности) в realtime превратить гораздо проще.
>>>В "монолите" (с трудом поворачивается язык называть так linux)
>
>Линукс не монолитное ???
FUSE(файлухи), CUSE(char devices), TUN(virtual networking) - вот ваш явный юзерспейс. И это только начало. У этих подсистем точно такие-же болезни, как и у сходных сервисов микроядра.
>>>Микроядро не имеет прямого отношения к безопасности и надежности. К ним имеет отношение _сложность_.
>
>а в чём сложность если ядро выполняет конкретные функции а в сё
>остальное в юзер спейсе
>Делай что хочешь. У тебя есть интерфейс управлению памятью, вводом/выводом, есть тот
>же таймер который в кернель спейсе, есть шедуллер И что мешает
>?
Сложность в структуре взаимодействия сервисов и негибкости интерфейсов. Кто-то же уже написал свой драйвер bluetooth и fbcon. Любое кардинальное изменение всё сломает.
>>>То, что в линуксе вызывает сегфолт(kernel ooops) и, возможно, оставляет примитивы синхронизации в нехорошем состоянии, в миниксе вызовет дедлок - на сообщение просто не ответят. Последствия ужасающи для всех задействованных подсистем.
>
>та кчто же правильнее дедлок или сегфолт который приводит к краху всей
>системы ?
А дедлок(eng. deadlock) не приводит? Не каждый дедлок приводит к зависанию(но некоторые приводят) и _далеко_ не каждый ooops приводит к панике ядра. Это идентичного рода ошибки. Угадайте, какие проще исправить без редизайна?
>>>В minix 2 офигенно достигалась стабильность: ядро и все сервисы ядра (и даже юзерспесный init!) были "скомканы" в один бинарь.
>
>прочтите релизнот миникса 3 и миникс3 и 2 это как небо
>и земля
>одним из главных отличий 3 от 2 это перенос драйверов устройств в
>юзер спейс
>и это круто так как драйвера каждый раз надо переписывать под новую
>аппаратуру
Последствия от падения - специфика драйвера. Про usermode linux слышали?
Это обычный юзерспесный процесс. Выполняет функции ядра linux. В нем можно, например, тестировать шедулер, файловые системы. Падение процесса - обычный сегфолт. Некоторые даже в production используют :]
>или разработчики всяких устройств договариваются с Торвальдсом о том что они хотят
>сделать изменения ?
Как кто. Мейнтейнеры сами занимаются поддержкой своих дров, получается очень и очень неплохо. Nvidia вообще плевать на Linus & co.
>я думаю скоро линукс будет микроядерным они к этому идут добиваясь RTOS
>
>темболее они хотять сделать линукс эмбеддед ОС
Уже давно в embedded. Причем с ростом характеристик встраиваемого железа linux вытесняет всё остальное со страшной силой.
