<ol>
<li>требование совместимости с NT вынуждает решить проблему с NT DPC,
приводящим в пиковых ситуациях к задержкам переключения процессора до
30-40 мс. Принято решение эмулировать NT DPC на уровне потока ядра с
приоритетом реального времени, а задачи "" реального времени
выполнять на приоритетах выше NT DPC, т.е. в отдельной группе приоритетов
жесткого реального времени, а сами NT DPC разбить на группы и
обеспечить их относительное выполнение с вытеснением (к сожалению,
больше в этом плане пока рассказать не могу - секрет ).</li>
<li>планируется поддержка linux на уровне подсистемы, поэтому
диапазон приоритетов ОС должен перекрывать диапазон приоритетов
linux.</li>
<li>предусматриваетя возможность динамического встраивания новых
классов объектов на уровне микроядра.</li>
</ol>
Исходя из вышесказанного простое заимствование решений из существующих
ядер меня не устраивает. Краткие характеристики ядра UzhOS с
комментариями:
<ol>
<li>диапазон приоритетов - 256, с 4 группами приоритетов:
<ul>
<li>приоритеты "" реального времени (64 + 32 специальных);</li>
<li>приоритеты "мя" реального времени (100);</li>
<li>динамические приоритеты (52);</li>
<li>ленивые приоритеты (8);</li>
</ul>
</li>
<li>новая концепция потока как контекста, в котором с вытеснением могут
выполняться до 16 уровней задач;</li>
<li>особая концепция отложенных обработок прерывания, способных
выполняться в контексте потока ядра с вытеснением (2 группы по 16 уровней);</li>
<li>особый алгоритм диспетчера объектов ядра (расширенная концепция
планировщика),позволяющий динамически встраивать в микроядро новые
классы объектов.</li>
<li>классы объектов микроядра, и всех остальных уровней, подчиняются
идее "каждый класс объектов может быть сигнальным, т.е. объявляющим
какие-либо события. Любой синхронный исполняемый объект может
блокироваться в ожидании события от любых одиночных или групп ".
Эта идея будет дополнена свойством "асинхронные объекты, ожидающие
события, планируются на ".</li>
</ol>
<i></i>: в качестве прототипа диспетчера прерываний был взят
диспетчер прерываний NT, концепция приоритетной обработки прерываний
полностью переработана. В качестве прототипа диспетчера объектов взяты
планировщик NT и нижний уровень менеджера объектов NT (как идея).
Алгоритм динамического планирования, как идея, также заимствован из NT
(планировщики *nix (в т.ч. linux) настолько слабы, что заимствовать оттуда
что-либо, хотя бы, как идею, не представилось возможным). Идея 5)
также заимствована из NT, т.к. ничего подобного по красоте и гибкости
я не встретил ни в одной другой архитектуре.
<br><br>
А что же заимствовано из *nix? ну, пожалуй, семафоры и пайпы. первые
стали популярными благодаря *nix, вторые - это изобретение unix.
<br>
Так, меня, кажется, понесло, закругляюсь
<br><br>
Все ядро UzhOS сверху донизу пронизано идеей модульности,
динамического конфигурировани и динамического добавления новых
классов объектов. Кроме того, на уровне конечных подсистем все классы
объектов предоставляют виртуальные методы, тем самым позволяя
"" на них механизмы удаленного доступа по принципу DCOM-CORBA.
<br><br>

<b><i>РХ:</i> Вы упоминали то, что собираете в UzhOS лучшее из существующих ОС, как вы
пришли к такой структуре? </b>
<br><br>
<i>СС:</i> Как я написал выше, необходимы свежие решения. К предложенной
архитектуре я пришел раньше, в период работы в области АСУТП,
связанной с жестким реальным временем, распределенным управлением
объектами, сетевыми решениями. Со временем некоторые решения
"". А когда встретил на сайте <a href=http://www.uzhos.tk>www.uzhos.tk</a>
предложение создать российскую ОС, я вышел со своим предложением.
<br><br>

<b><i>РХ:</i> Вы часто упоминаете, что одним из идейных вдохновителей концепции ядра
UzhOS стало ядро NT, основанное, в свою очередь, на достижениях VMS. Вы
планируете использовать для своего ядра какие-либо части, разработанные
в других проектах, как то <a href=http://www.reactos.org/>ReactOS</a> или
<a href=http://www.openvms.org/>OpenVMS</a>?</b>
<br><br>
<i>СС:</i>
К сожалению, даже при всем моем желании "" что-нибудь из
ReactOS на этапе разработки микроядра мне это не удастся, т.к. у
меня принципиально иное микроядро. Но, если говорить о прямом
копировании решений, это всегда приводит к плохим пародиям на
существующие ОС. Очень наглядный пример тому - это как раз ReactOS,
которая в своем стремлении к полной двоичной совместимости (на уровне
структур ядра) и стала смешной пародией на NT, да и к тому же, в
основном, с плохо написанным кодом. Хотя некоторые отдельные решения
в ReactOS мне понравились. Например, механизм реализации виртуальных
методов классов микроядра в ReactOS лучше, чем в NT (как механизм).
<br><br>
Но с другой стороны, реализацию каких-то отдельных утилит или
процедур я не считаю зазорным подсмотреть, чтобы потом сделать по-своему, тем
более, если в заголовке модуля написано "програма написана в надежде,
что она кому-нибудь может пригодиться" А что-то заимствовать из
кода VMS я не вижу смысла, т.к. все ее решения я знаю давно и хорошо,
и смогу их реализовать, не заглядывая в код (это, впрочем, касается и многих
других ОС). К тому же, это, все-таки, уже прошлое...
<br><br>
К счастью, реализовать совместимость с NT легко, т.к. в основном,
ее классы инкапсулированыи не требуют полной совместимости на уровне
структур. Но и в иных случаях, например, при реализации POSIX, можно
создать прослойку, изолирующую структуры POSIX от ядра UzhOS.
<br><br>

индекс статьи
страница 1 : страница без заголовка
страница 2 - текущая : страница без заголовка
страница 3 : страница без заголовка