не сказал бы так. например есть задание - написать уникальную ОСь для банковского сервера, при чем могут в этот сервер "суваться" различные железки от разных производителей. Будет ли она популярна? Конечно же нет. Единственный экземпляр. Будет ли она защищенной на том основании, что непопулярна? Ответ тот же - нет. Может жажда денег взбаламутит голову писателям драйверов и они вставят в код собственную закладку для откачки денег на собственные счета. Контраргумент можно привести такой, что кто же будет писать драйвер для своего продукта дял столь малораспространненной ОСи. Ответ - если рассматривать производителей узкоспециализированного железа, тиражируемого в малых количествах, то скорее всего портирование - это только вопрос денег. И как предлагаешь отслеживать такие ситуации? Такой пример тривиален. А вот если указать 0 при вызове сис. функции? Ну или даже не 0, а просто невалидное значение? Отслеживать колстек в поисках откуда ноги растут? +1
ну так нужно либо делать гибрид, либо делать второй тип подключаемых модулей помимо драйверов. которые будут функционал ОС наращивать полностью соглсен что у NT ядро отстойное, да дело даже не в анализаторе, а в концепции. есть драйвера, которым не критична скорость - так почему бы их не вынести на кольцо защиты повыше. насчет анализа вероятность разрущений - как ты это сделаешь? во-первых, анализировать что-либо в обработчике KeBugCheckEx бессмысленно, т.к. уже поздно. Восстановить работу будет весьма проблематично, потому как она объявлена как noreturn и в некоторых местах сразу на ее вызовом идет другая ветка кода, которая может породить каскад икслючений/багчеков, что не закончится ничем хорошим. А вот анализировать причину возникновения ошибки можно было бы в KeBugCheckEx вполне, если бы это сделали на более ранних этапах проектирования системы. Вообще, если бы NT спроектировали сразу нормально, получилось бы гораздо лучше, чем то, что мы имеем сейчас: совместимость со старымыи версиями, которая тащит за собой сотни килобайт кода, дыры в безопаности и тормоза. Мне, например, глубоко фиолетово, будет ли моя программа работать на 9x или NT4. Можно было вполне сделать опционально две системы - та, что будет совместима, но глючна (это, грубо говоря, то, что мы имеем сейчас) и нормальную. Ладно, я что-то немного отвлекся. В любом случае тип ядра, как уже сказано, определяется конкретными целями и постановкой задачи.
_basmp_ можно: драйвер ринг3 по определению работает через ось и его запросы к железу модерируются, а ринг0 может модерироваться посредством эмуля.
О микроядрах. Так пример. Имел я как-то дело с QNX. Сразу говорю халтуры там хватает, но.. на моем P2-500 все ОК. Там еще куча неинтеловского железа поддерживается. В QNX так и сделано. Не происходило ниразу. Хотя может мало издевался. Тоже не было. Хотя, впрочем, драйвера там - обычные запускаемые elf-ы поддерживающие специальный протокол и ничто не мешает перезапустить такой драйвер скажем с вирт. диска в памяти. В QNX драйвера работают в 1-м кольце, а ядро в 0. Это да тормозит. Хотя я думаю больше из-за связи через механизм сообщений. Впрочем тут есть большой +. В QNX поток ядерных сообщений (не помню как называется точно) можно направить в сеть по специальному протоколу. Таким образом две QNX машины становятся одной, что незаменимо для работы со всякими девайсами. Машины могут быть на разном железе. То-же справедливо и для 2,3,..15 процов/ядер. Несомненно. Однако, почему-бы и не обсудить. В дискуссиях бывает рождается истина.
то бишь есть еще один драйвер (проверяющий) знающий о вашем нестандартном железе и его протоколах? а скорость? А через 5-7 лет все заново? МС сразуже потеряет все свои преимущества (большой обьем поп по). И ее тут-же накроет какой нибудь линукс. Почему интел до сих пор выпускает процы с системой x86? Допустим, что нашелся банк котрый наскреб деньги на написание уникальной оси с нуля и на производителей, чтоб они написали драйвера (спецификации вам не дадут, особенно к банковским железякам). Допустим, он дождался пока это все будет сделано и отлажено хотя-бы в первом приближении. Допустим, он посадил полусырую ось на деньги. Как вы будете атаковать этот черный ящик? Как американских фильмах про хакеров, в стиле дума? Хотя может этот сумасшедший банк выложит спецификации где-нибудь в инете.. Пример: сейчас полно всякого закрытого железа на контроллерной основе - тюнера, телефоны - попробуйте что-то вытащить из них не родным способом, оцените затраты, подумайте, что произойдет раньше - выгорит ваше дело или вас засекут (банк все таки). А вообще-то все эти названия.. - это так... Книгу сперва пишут, а потом придумывают ее имя. Например Bluebottle - ось какого типа?
Неубиваемой может быть и микроядерная система, и система с монолитным ядром -- всё зависит от качества проектирования и реализации. Ну а теоретические преимущества/недостатки того и другого подхода уже описал rei3er. Если вкратце его суммировать, то получится, что микроядерную ось проще сделать надёжной, а с монолитным ядром -- быстрой. Хотя, имхо, при идеальной реализации выгоднее монолитное ядро: оно будет столь же надёжно, как и микроядро (на то и идеальная реализация ), но при этом быстрее.
В смартах это так и есть, но учтите, что скажем для нокии от 6600 до n8* (не помню точно, но от 6630 до n73 одно железо точно) железо практически не менялось, только слегка увеличилась частота (с 130 до 220 MHz) и ОЗУ. Малейшее изменение аппаратной части требует переписывания/сборки/отладки всей системы. Это возможно только для полностью закрытых систем (всякие мобилы-пальмы) где производитель контролирует и софт и хард. Микроядра используются в ситемах с заранее малоопределенной архитектурой, в которых обеспечение поддержки новой периферии превыше всего. В них микро не только ядра, в этих системах буквально каждая функция выделена. В результате грузится и работает прога медленее - много межмодульных связей. Но для доводки нужно переписывать минимум. О надежности микроядер и вообще о них сходите на qnx.org.ru лучше по русски вы нигде не спросите/почитаете. Их сила совсем не в надежности - она чуть выше среднего, зависит сколько вы компонентов установите/запустите/глючности драйверов - то бишь как писал касперский может отвалиться память или диски или порт какой нибудь, но система не зависнет и оставшиеся независимые компоненты будут работать - такая себе полунадежность, но лучше, чем ничего. Скажем, у нас все цифровые АТС ходют под QNX.
я могу будучи рутом угробить весь жесткий диск одной командой в Linux да и любая программа, работающая под рутом, тоже в Windows, насколько я понимаю, это также возможно (там же есть файлы устройств?) так что один фиг здесь, что микроядро, что монолитное/гибридное в Linux большинство таких ситуаций отслеживается но только при выполнении следующий условий 1. прямо или косвенно должен выполняться код загружаемого модуля 2. счетчик преемтивности = 0 (иначе дальнейшие действия небезопасны) тогда ядро вызывает деструктор модуля (module -> cleanup()), уничтожает процесс, в контексте которого произошла ошибка и осуществляет переключение контекста
я бы все-таки отдал предпочтение в таком случае микроядру чем лепить все в одну кучу и потом с ней работать, лучше сделать несколько кучек и наладить их взаимодействие мне тут сразу вспомнилась аналогия с БД что лучше, привести ее к 5НФ или лепить все в 1-2 таблицы? стройность и мастабируемость архитектуры на сегодняшний день важнее скорости все имхо
rei3er Ну, тут можно поспорить насчёт кучи. Монолитное ядро ещё не означает беспорядочную свалку всего и вся. Ничто не мешает отделить одни функции от других, тщательно задокументировать, описать интерфейсы и т.п., а потом сваять по полученным спецификациям ядро. Компоненты его будут взаимодействовать друг с другом не менее чётким и понятным образом, чем в микроядерной системе, и единственная разница, по сути, будет заключаться в отсутствии переключений контекста, откуда -- более высокая скорость. С другой стороны, микроядерная ось -- это тоже "куча". Ведь от самого голого микроядра толку никакого на практике нет, нужно сваять изрядное количество других компонентов. Если не прописать чётко порядок их взаимодействия друг с другом -- получим микроядерный бардак, и ничего более. В общем, ИМХО, успех реализации оси процентов на 80 зависит от качества предварительного проектирования и лишь на 20 -- от кодирования и отладки.
_basmp_ Никак нет. Если система изначально не написана криво. Например, если драйверы внешних устройств являются модулями, хотя и выполняющимися в адресном пространстве и с привилегиями ядра, но всё же не "впаянными" намертво в него, то добавление нового устройства сводится к написанию нового драйвера и его отладке, всё остальное менять не требуется. Вот если меняется архитектура процессора или там происходят кардинальные изменения в системе прерываний -- тогда другое дело. Но это говорит скорее о незрелости аппаратной платформы или криворукости её создателей (яркий пример -- как раз интеловская архитектура начиная с 8086).
SII ничего не мешает только это полная аналогия с кодом, написанном на С и Pascal С - моноядро, Pascal - микроядро аналогия понятна? получим, не спорю преимущество микроядерной архитектуры в том, что она определяет более высокий уровень программирования т. е акценты смещаются в сторону логики, а не системных деталей возьмем ту же сетевую подсистему на примере Linux там смешаны в кучу как низкоуровневые механизмы типа отложенных прерываний, так и логика работы различных протоколов логика работы протоколов - это самый что ни на есть прикладной уровень, он вообще не зависит ни от архитектуры процессора, ни от других системных деталей задача микроядра - предоставить возможность получить драйверу устройства пакет и все тем самым мы отделяем мух от котлет и можем сосредоточится не на деталях реализации ядра (в случае моноядра), а на, собственно, стеке протоколов
Я не буду ввязываться в дискусию по сравнению анатомий ядер операционных систем, лишь от себя могу добавить практический пример. У меня тут встраиваемая технология на базе ПиСи104, для АСУ ТП и всего им подобного. Изначально, еще до меня, софт писался в виде обычной ДОСовской 16-разрядной проги. Линейное написание - отсутствие неявностей и мудрёностей в коде, нормальная отладка и обкатка перед внедрением на объект гарантировала надежность, монолитность обеспечивала быстродействие. Потом применили переключение в протект мод, алгоритмы перенесли на 32-разрядный код, но сохранился подход к реализации, а точнее его отсутствие. Та же линейность, монолитность, без заморочек, чем проще, тем меньше места для ошибок. Начали появляться новые железки, заказчиков интересовала дополнительная функциональность. Все дорабатывалось и дописывалось, иногда складывалось так, что закладывал функциональность один, а расширял потом ее другой. И что получилось спустя несколько лет, когда пришлось мне рулить эту штуку? Предо мной предстали 2 мегабайта ассемблерных текстов линейно написаной проги. Задача, которую я должен был реализовывать затрагивала самые низы, т.е. новая функциональность должна была управлять всем этим делом (запуск, останов, съем дампов, контроль состояния железа), т.е. своего рода виртуальный оператор. Абстрагированости никакой, логическое разделение - лишь неясные очертания. Пришлось много извращаться. При отладках моск вобще закипал на ура. Простота и немудреность превратились в кашу и нелогичность, причем еще до меня. Дописываешь одно - цепляешься за другое, быстродействие - чтобы выполнить какое то действие, приходится проверять с десяток условий. Ну кое как справился. А когда дело было сделано, меня повергло в шок следующее задание - портировать тексты на новое железо О_о. Вот вам и монолитность. У меня муравьи по коже когда я этот термин вижу или слышу. Плюнул я на все. Щас у меня уже 6 модулей, связанных между собой пабликами/экстернами, образующих пока еще простенькое микроядро. На каждую фичу по модулю (GDT, IDT, кейбоард, видео, командный shell, загрузчик). Все это модульно, но линкуется в монолитную структуру. В недалеком будущем shell я собираюсь вынести в другое кольцо и оформить ввиде TSS как и драйвера периферийного железа. И не то, чтобы писать драйвер памяти, теперь я согласен буду написать драйвер для самого процессора , если это будет необходимо. И все это ради того, что бы добавление строк в фукции для работы с АЦП не привносило сочных эксепшенов в фукции для работы с хардом. Ведь мне дорога моя психика. Если во время работы отвалится полсистемы, без разницы, програмно или физически, все равно будет крутиться протокол сервисного канала, который сообщит оператору, что их осталось только двое, да выкинет какие нить блокировки, дабы некий редуктор по инерции не попытался устремиться в деревню к деду. Такая "полунадежность" действительно оптимальна, да и более того, крайне необходима. Но еще хочу добавить, что, возможно, не столько важен выбор архитектуры ядра. Думаю, можно придерживаться идеологии гибридов. По крайней мере это будет оптимальным решением в большинстве случаев. Более важным здесь, имхо, является строго определиться с функциональной декомпозицией, с подходами к абстрагированию, с техникой изложения алгоритмов в текстах, дабы нарисованная когда то функция не стала в будущем мылом, а то вдруг в тот момент еще и веревка под руку попадет. Ведь программинг это не столько печатанье путем кнопкоклацанья, сколько технологии абстракций и мышления. Наболело все-таки.
rei3er Эээ... Попробую угадать... Подавляющее большинство программ на паскале, которые я видел, вызывали у меня ассоциацию с кучей нечитаемого хлама, беспорядочно сваленной в одном месте. Должен ли я делать вывод, о том, что ты считаешь идею микроядра бредовой?
Несколько сотен профи после многих лет работы так и не смогли сделать неубиенное ядро, не содержащее багов, ошибок и просто мусора, который в объектно-ориентированных системах не так-то просто подчистить .... С линуксом та же ф... Существует ли оъективная причина такого положения вещей? Была идея - сделать микроядро, и каким-то образом запретить любые его изменения. Функции, типа АПИ (дубликат функций ядра, которые тоже недоступны) - предоставляются приложениям на стадии компиляции, т.е. нет динамических библиотек вообще - только статические. Приложения увеличатся в размерах, зато пошустрее будут работать и меньше загружать процессор, мне кажется...
masm32 Да. Есть такое утверждение: любая программа содержит, по-крайней мере один баг, и может быть уменьшена, по-крайней, мере на один байт.
rei3er Если честно, не совсем. Вы говорите о... э... том, что паскалеподобные языки поощряют тщательное проектирование, а Си -- наоборот, программирование вслед за "потоком сознания"? Не спорю, но это проблемы Линуха. Некоторым я, безусловно, надоел своим нытьём про старые системы, но не могу не припомнить их снова. В моей любимой RSX-11M такие вещи, как файловые системы и сетевые протоколы, поддерживались специализированными задачами (так называемыми вспомогательными управляющими процессорами -- ACP), которые работали в собственных адресных пространствах и наравне с обычными пользовательскими задачами делили процессорное время, конкурировали за память и т.д. А в ядре были реализованы лишь драйверы "железа". Тем не менее, RSX-11M -- самая что ни на есть система с монолитным ядром. Просто в это ядро не набивали всё подряд, как было сделано в Вындовзе или Линухе. Поэтому добавить новый сетевой протокол или файловую систему в RSX-11M -- буквально раз плюнуть. Во время оно (году эдак в 1993-м) я извращался по этому поводу: присобачил к СМ-1600 (наш клон PDP-11) флопик от ПК с самопальным контроллером, к которому написал драйвер (модуль ядра) и ACP, реализующий FAT-12/16. Работало, проблем никаких не возникало. Кстати, на той же дискете можно было создавать и штатную файловую систему RSX-11 (Files-11 называется), а на "родных" дисках СМ-1600 -- FAT12/FAT16, поскольку ACP плевать, с каким драйвером работать, а драйверу -- с каким ACP, лишь бы устройства были подходящего класса (в данном случае -- дисковые накопители). Разве что загружаться с дискеты нельзя было -- начальные загрузчики зашиты в ПЗУ машины были, причём никаких флэш-памятей тогда не было -- однократно программируемые микросхемы, к тому же впаянные намертво. Barbos Так дело не в монолитности, а в бессистемности. Делали как попало -- вот и получили то, что получили. К сожалению, это обычный способ разработки ПО... masm32 Ну так раздутые программы, куча разработчиков -- вот и проблемы. Делить надо, однако Что в микроядерных системах выполняется намного легче: там сама "природа" микроядра принуждает к чёткому делению, а в монолитном ядре разработчикам надо в определённом смысле насиловать самих себя, чтобы не пытаться сделать, "как проще" и "как быстрее".
Почитав, что Вы все здесь написали, я могу составить такую таблицу: Микроядро: Позитивные стороны: 1) Если сервис упадет, он не сокрушит всю систему ( теоретически ) 2) Можно включать или отключать ненужные сервисы Негативные стороны: 1) Долгое переключение задач (по сравнение с программным) 2) Менее защиты по сравнению с монолитом (это мое мнение, можно и не учитывать) Монолитное ядро: Позитивные стороны: 1) Быстрота разработки 2) Быстрота работы ядра 3) Используя модульность – возможность изменять части ядра без перекомпиляции Негативные стороны: 1) Если в драйвере или части ядра есть ошибка – то вся система рухнет 2) Увеличение кода ядра – если пользоваться модульностью – проблема исчезает Таблица не полная – добавляйте кто что считает нужным
AntiB В общем согласен, кроме меньшей защищённости микроядерной системы. Защищённость вообще никак от архитектуры не зависит.
