1) почему микроядро — это хорошо ?
2) почему микроядро не медленнее традиционных ядер ?
3) каким (эффективным) образом реализуется механизм доставки сообщений серверам ?
4) есть ли реализации микроядра второго поколения (микромикроядра) ?
А кто сказал, что микроядро, это есть хорошо? Я не вижу смысл создавать систему с микроядром. Многие утверждают, что если система основана на микроядре, она более устойчива. Я не вижу в этом смысла. Да, система иожета завершить процесс вызвавший фатальную ошибку без "синих экранов". Но будет ли система без жизненно важного процесса нормально (в полном смысле этого слова) продолжать функционировать? Да, возможно разработка компонентов ядра станет задачей полее просто, но стоит ли игра свеч?
DAS>Пара вопросов по архитектуре микроядра.
DAS>1) почему микроядро — это хорошо ? DAS>2) почему микроядро не медленнее традиционных ядер ? DAS>3) каким (эффективным) образом реализуется механизм доставки сообщений серверам ? DAS>4) есть ли реализации микроядра второго поколения (микромикроядра) ?
Здравствуйте, htfv, Вы писали:
H>А кто сказал, что микроядро, это есть хорошо? Я не вижу смысл создавать систему с микроядром. Многие утверждают, что если система основана на микроядре, она более устойчива. Я не вижу в этом смысла. Да, система иожета завершить процесс вызвавший фатальную ошибку без "синих экранов". Но будет ли система без жизненно важного процесса нормально (в полном смысле этого слова) продолжать функционировать? Да, возможно разработка компонентов ядра станет задачей полее просто, но стоит ли игра свеч?
Слушай, а что такое по-твоему микроядро? Ты его часом с защищенным адресным пространством не путаешь?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, htfv, Вы писали:
H>>А кто сказал, что микроядро, это есть хорошо? Я не вижу смысл создавать систему с микроядром. Многие утверждают, что если система основана на микроядре, она более устойчива. Я не вижу в этом смысла. Да, система иожета завершить процесс вызвавший фатальную ошибку без "синих экранов". Но будет ли система без жизненно важного процесса нормально (в полном смысле этого слова) продолжать функционировать? Да, возможно разработка компонентов ядра станет задачей полее просто, но стоит ли игра свеч?
VD>Слушай, а что такое по-твоему микроядро? Ты его часом с защищенным адресным пространством не путаешь?
Гы!
В классической системе на основе микроядра основные компоненты операционной системы (диспетчеры памяти, процессов, ввода-вывода) выполняются как отдельные процессы в собственных адресных пространствах и представляют собой надстройки над примитивными сервисами микроядра.
Теперь рассмотрим следующую ситуацию. Допустим, в коде файловой системы (или, например, в диспетчере памяти) имеется ошибка, которая время от времени приводит к краху системы. В истинной ОС на основе микроядра подобные компоненты выполняются в пользовательском режиме, поэтому теоретически ошибка приведет лишь к завершению процесса соответствующего компонента. Но на практике такая ошибка все равно вызовет крах системы, так как восстановление после сбоя столь критически важного процесса невозможно.
Вот, что я пытался сказать. Только уже поздно было, и голова гудела . По моему, системы, построенные строго по принципу микроядра, непрактичны из-за слишком низкой эффективности.
Здравствуйте, VladD2, Вы писали:
VD>Т.е. ты считаешь что Фришка и NT 3.51 (да и XP) менее быстры чем Линукс? Или под эффектвностью ты понимешь нечто другое?
XP это не чистое микроядро. Начиная с NT4 как минимум драйвера видео работают в нулевом кольце
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, VladD2, Вы писали:
VD>>Т.е. ты считаешь что Фришка и NT 3.51 (да и XP) менее быстры чем Линукс? Или под эффектвностью ты понимешь нечто другое?
AVK>XP это не чистое микроядро. Начиная с NT4 как минимум драйвера видео работают в нулевом кольце
XP вообще не микроядро. Вот. Возьми любую книгу описывающую ядро (например, Соломона и Руссиновича) и найдешь много подтверждений тому. Вообще, с NT3.51 и до .NET Server Microsoft все больше и больше кода переносит в ядро (в том смысле, что он работает в Kernel Mode). Например, в Windows2000 появились спец. сервисы для IIS 5.0. IIS 6.0 в .NET Server'е уже наполовину в Kernel Mode.
Здравствуйте, htfv, Вы писали:
VD>>Слушай, а что такое по-твоему микроядро? Ты его часом с защищенным адресным пространством не путаешь?
H>Гы!
Ты не даешь определения микроядра.
H>В классической системе на основе микроядра основные компоненты операционной системы (диспетчеры памяти, процессов, ввода-вывода) выполняются как отдельные процессы в собственных адресных пространствах и представляют собой надстройки над примитивными сервисами микроядра.
Основная идея микроядра — оно предоставляет только самые базовые функции — файлы, память, процессы, потоки, обмен данными и тд.
H>Теперь рассмотрим следующую ситуацию. Допустим, в коде файловой системы (или, например, в диспетчере памяти) имеется ошибка, которая время от времени приводит к краху системы. В истинной ОС на основе микроядра подобные компоненты выполняются в пользовательском режиме, поэтому теоретически ошибка приведет лишь к завершению процесса соответствующего компонента. Но на практике такая ошибка все равно вызовет крах системы, так как восстановление после сбоя столь критически важного процесса невозможно.
Такая же ситуация возникает и без микроядра.
А вот реалтайм без микроядерной архитектуры почти невозможен.
Здравствуйте, AndrewVK, Вы писали:
VD>>Т.е. ты считаешь что Фришка и NT 3.51 (да и XP) менее быстры чем Линукс? Или под эффектвностью ты понимешь нечто другое?
AVK>XP это не чистое микроядро. Начиная с NT4 как минимум драйвера видео работают в нулевом кольце
Драйвера и так работают в нулевом кольце, иначе издержки на переключение контекста обходятся очень дорого.
В Nt,2000,XP двухколечная архитектура ОС. Пользователь сидит в 3м кольце.
Здравствуйте, htfv, Вы писали:
AVK>>XP это не чистое микроядро. Начиная с NT4 как минимум драйвера видео работают в нулевом кольце
H>XP вообще не микроядро. Вот. Возьми любую книгу описывающую ядро (например, Соломона и Руссиновича) и найдешь много подтверждений тому. Вообще, с NT3.51 и до .NET Server Microsoft все больше и больше кода переносит в ядро (в том смысле, что он работает в Kernel Mode).
Kernel Mode — это не ядро. Это режим такой. А само ядро — ntoskrnl + hal.
Запусти depends ntoskrnl.exe и посмотри, что экспортируется.
Драйверами занимается целая подсистема — это Kernel Mode но уже не ядро.
А в Линуксах всяких в ядре сидят и драйвера всякие, и много всякого мусора.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>А вот реалтайм без микроядерной архитектуры почти невозможен.
Логично. Хотя если сильно урезать количество сервисов то можно и без. Вобще понятие реалтайм растяжимое. Все зависит от того какое устраивает время реакции. В NT4 гарантировано для реалтайм процесса лаги не более 150мс. Если реалтайм задача допускает такие лаги то и NT в этом случае реалтайм-система.
Здравствуйте, AndrewVK, Вы писали:
AVK>Логично. Хотя если сильно урезать количество сервисов то можно и без. Вобще понятие реалтайм растяжимое. Все зависит от того какое устраивает время реакции. В NT4 гарантировано для реалтайм процесса лаги не более 150мс. Если реалтайм задача допускает такие лаги то и NT в этом случае реалтайм-система.
Тут не время играет роль. Для реалтайма строго детерминированное время отклика системы.
А в NT отклик системы — случайная величина и 150мс это среднее значение.
Ответа при большой загрузке можно и не дождаться.
Для реалтайма делают ядра сверхлегкие, чтобы они были прерываемы.
NT не прерываема в системной секции, поскольку ядро этого не позволяет.
Реалтаймные системы позволяет за счет этого работать при пиковой загрузке (в корень из двух раза выше рабочей), а обычные(многозадачные) — только на рабочей (в корень из двух раза выше средней)
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Тут не время играет роль. Для реалтайма строго детерминированное время отклика системы.
Нет. Реалтайм это когда гарантированно непревышение времени отклика определенной величины.
OE>А в NT отклик системы — случайная величина и 150мс это среднее значение.
Максимальное.
OE>Ответа при большой загрузке можно и не дождаться.
Для realtime priority не может быть большой нагрузки, все стоят и курят. В этот момент даже мыша по экрану не ездит.
Можно конечно сделать несколько реалтайм потоков, но тут уж ты сам себе злобный буратина.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Здравствуйте, htfv, Вы писали:
AVK>>>XP это не чистое микроядро. Начиная с NT4 как минимум драйвера видео работают в нулевом кольце
H>>XP вообще не микроядро. Вот. Возьми любую книгу описывающую ядро (например, Соломона и Руссиновича) и найдешь много подтверждений тому. Вообще, с NT3.51 и до .NET Server Microsoft все больше и больше кода переносит в ядро (в том смысле, что он работает в Kernel Mode).
OE>Kernel Mode — это не ядро. Это режим такой. А само ядро — ntoskrnl + hal. OE>Запусти depends ntoskrnl.exe и посмотри, что экспортируется. OE>Драйверами занимается целая подсистема — это Kernel Mode но уже не ядро. OE>А в Линуксах всяких в ядре сидят и драйвера всякие, и много всякого мусора.
ntoskrnl+hal всего лишь реализуют основные сервисы ядра. Остальные компоненты не работают в защищенном пространстве. Они не являются процессами, что противоречит концепции микроядра. В Линуксах драйвера в ядре потому, что они туда слинкованы. При компиляции ядра ты запросто можешь сказать, что тот или иной драйвер должен грузиться динамически. Архитектура у Линукса просто другая (менее ли она гибкая или нет не является темой данного разговора). В Windows NT просто все драйвера грузятся динамически на основании данных в реестре. Все связи осуществляются на стадии исполнения. Вот и вся разница. Конечно, с приходом WDM все стало еще интереснее. Грубо говоря, загружаемые драйвера определяются самими устройствами, а не наоборот.
В общем, принципиальной разницы между ядром NT и Linux я не вижу. Linux тоже не является системой основанной на микроядре. Вот.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Здравствуйте, htfv, Вы писали:
VD>>>Слушай, а что такое по-твоему микроядро? Ты его часом с защищенным адресным пространством не путаешь?
H>>Гы!
OE>Ты не даешь определения микроядра.
H>>В классической системе на основе микроядра основные компоненты операционной системы (диспетчеры памяти, процессов, ввода-вывода) выполняются как отдельные процессы в собственных адресных пространствах и представляют собой надстройки над примитивными сервисами микроядра.
OE>Основная идея микроядра — оно предоставляет только самые базовые функции — файлы, память, процессы, потоки, обмен данными и тд.
Повторяю. В классической системе на основе микроядра основные компоненты операционной системы выполняются как отдельные процессы в собственных адресных пространствах. Это включает в себя и менеджер памяти, и файловые системы (которые, кстати, можно реализовать в user mode'е и в NT), и менеджер потоков (примерно как fiber'ы в NT).
H>>Теперь рассмотрим следующую ситуацию. Допустим, в коде файловой системы (или, например, в диспетчере памяти) имеется ошибка, которая время от времени приводит к краху системы. В истинной ОС на основе микроядра подобные компоненты выполняются в пользовательском режиме, поэтому теоретически ошибка приведет лишь к завершению процесса соответствующего компонента. Но на практике такая ошибка все равно вызовет крах системы, так как восстановление после сбоя столь критически важного процесса невозможно.
OE>Такая же ситуация возникает и без микроядра.
Я пр это и говорю. Микроядро не является сколько-нибудь более стабильной системой.
OE>А вот реалтайм без микроядерной архитектуры почти невозможен.
Вопрос о realtime OS серьезно не изучал. Это довольно специфичный предмет. Сказать, что без микроядра реалтайма нет, я не могу. Не вижу причин. Просто NT не разрабатывалась как реалтайм ОС и не преследует такой цели. Вот и все.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Тут не время играет роль. Для реалтайма строго детерминированное время отклика системы. OE>А в NT отклик системы — случайная величина и 150мс это среднее значение. OE>Ответа при большой загрузке можно и не дождаться.
Вот и подумай о том что ты говоришь.
OE>А вот реалтайм без микроядерной архитектуры почти невозможен.
ДОС построеный вообще без архитиктуры прекрасно подходит для реалтайм-задач. А NT построеная по микроядерной архитектуре для релтайма не пододит.
Еще раз тебе говорю, ты путаешь защиту адресных пространств и микроядерную архитектуру. Вся линейка NT и все чистокровные Юниксы основаны на микроядерной архитектуре. А вот Линукс как раз выходит из этого ряда. Микроядерность влияет исключительно на переносимость ОС. Микроядро — это та часть ОС которая полностью зависит от железа и которую обычно пишут на ассемблере.
Здравствуйте, htfv, Вы писали:
H>ntoskrnl+hal всего лишь реализуют основные сервисы ядра. Остальные компоненты не работают в защищенном пространстве. Они не являются процессами, что противоречит концепции микроядра. В H>Линуксах драйвера в ядре потому, что они туда слинкованы.
Потому оно и не является микроядром, потому что предполагает макрофункциональность- сервис предоставляемый драйвером.
H>При компиляции ядра ты запросто можешь сказать, что тот или иной драйвер должен грузиться динамически. Архитектура у Линукса просто другая (менее ли она гибкая или нет не является темой данного разговора). В Windows NT просто все драйвера грузятся динамически на основании данных в реестре. Все связи осуществляются на стадии исполнения. Вот и вся разница. Конечно, с приходом WDM все стало еще интереснее. Грубо говоря, загружаемые драйвера определяются самими устройствами, а не наоборот.
В том то и разница, что к ядру драйвера не имеют никакого отношения. Это и отличает не только NT от Linux, но и микроядро от модульного.
Здравствуйте, VladD2, Вы писали:
OE>>Тут не время играет роль. Для реалтайма строго детерминированное время отклика системы. OE>>А в NT отклик системы — случайная величина и 150мс это среднее значение. OE>>Ответа при большой загрузке можно и не дождаться. VD>Вот и подумай о том что ты говоришь.
Все правильно, для реалтайма загрузка не должна иметь влияния.
OE>>А вот реалтайм без микроядерной архитектуры почти невозможен. VD>ДОС построеный вообще без архитиктуры прекрасно подходит для реалтайм-задач. А NT построеная по микроядерной архитектуре для релтайма не пододит.
Удинственно, что можно сделать с ДОС для реалтайма — переключиться в защищенный режим
(EMM386, DOS4GW,DPMI ) и самому написать реалтайм ядрышко — но это уже не ДОС.
Сам ДОС — это монолитная архитектура с модульным уклоном. Причем архитектура весьма четкая и простая.
Время отклика не детерминировано и нет многозадачности встроенной.
Многозадачность довольно сложно реализовать из-за нереентерабельности ДОС.
Я пять лет программил под ДОС на всем почти, что было — TP,BP,TC,BC,ASM + машинные коды и реалтайма нашел не очень много.
О каком реалтайме может идти речь, если в момент, когда дос внутри себя,
не будет отклика ни на что ?
В ДОС такая парадигма —
1. Во время инициализации нужно перепрограммировать таймер, сесть на 8h,9h,16h,10h,13h,21h,28h,33h, 70h + желательно еще несколько перерываний. Это нужно что бы увеличить шанс срабатывания.
1а. функция 34h прерывания 21h возвращает адрес флага занятости системы.
1б. функцию не помню точно — возвращает состояние текущей задачи — файловые буфера и внутренние переменные и тд — это надо скопировать себе где нибудь.
2. по аппаратному прерыванию взводится флаг, показывающий, что нужна обработка.
3. В каждом обработчике вызывается функция для проверки занятости прерывания. В 28h это можно не делать.
4. Переключаем сегмент стека, сегмент данных
5. Подменяем состояние ттекущей задачи
6. Делаем свое черное дело
7. Возвращаем управление обратно с восстановлением всего контекста задачи и тд.
Итого
1. пункты с 3го по 7й выполняются довольно долго. В это время никакой обработки вложенных прерываний не будет.
2. Отклик системы — время с 2го по 7й пункт весьма велико. Интервал между 2 — 3 стремятся уменьшить за счет большого количества перехваченных прерываний — количество оказий. Если есть возможность, программируются прерывания от портов последовательного и параллельного портов — еще два таймера.
. По моему, системы, построенные строго по принципу микроядра, непрактичны из-за слишком низкой эффективности.
