UzhOS, крепчи стали!

Дата: 10/03/05; 


Молодой проект УжОС просто не может не украсть вашего внимания. Помимо того, что операционная система задумана максимально грамотно, она ещё собирается эмулировать подсистемы Windows NT. Вполне возможно, что в ближайшем будущем (через год? через два?) система получит распространение не только среди любителей низкоуровневого программирования, но и среди обычных обладателей персональных компьютеров. Ознакомиться с УжОС вам позволит уникальное интервью с координатором проекта!

1. Почему вы решили написать свою ОС?
  Небольшой экскурс в прошлое. Я увлекся программированием на производстве, и поэтому основная моя деятельность, как программиста, была связана с задачами АСУТП, сетями, системами реального времени. Сначала меня покорили своей красотой архитектуры ЭВМ PDP11 и VAX11 фирмы DEC, и операционные системы RT11, RSX11, VMS, разработанные командой виртуозов. Изучение этого прогораммно-аппаратного ряда являлось хорошей школой программирования в реальном времени, от простого к сложному. Стремление создать что-то свое, с одной стороны, и жесткие требования к разработке встроенных систем "под ключ" с другой стороны, приводило к тому, что я создавал операционные ядра для встроенных систем управления сначала на платформе DEC, потом и на Intel. Но, хотя мне всегда хотелось сделать что-то более серьезное и значительное, текцущая работа "засасывала", отнимала все время... В программировании наступила эпоха ЭВМ "для домохозяек", все в один голос кричали: "Зачем мне многозадачность, когда я с одной задачей толком не справляюсь!..." "Семейство DEC - самая удачная промышленная диверсия США в СССР..." и тому подобную чушь. Мир заполонило поколение ОС - "уродов": MS-DOS, Windows 3.1, Windows 95... В конце концов я махнул рукой и расстался с мыслью о создании своей ОС... (меня, наверное, спросят, а что это я про DEC да про Микрософт, а как же Unix? Многозадачная версия Unix появилась в 1974 году, когда уже существовали многозадачные ОС жесткого реального времени RT11 и RSX11. Unix был основан на примитивном круговом планировании по таймеру, и таким оставался до начала 80-х годов, поэтому с точки зрения реального времени он никакого интереса не представлял, ну а затем вместе с DEC был надолго "задвинут") Однажды я случайно наткнулся на subscribe.ru на приглашение продписаться на рассылку "сделай свою операционную систему". Наверное, это совпало с каким-то рубежом в моем творчестве, и я опять загорелся... А Билл Гейтс (далее БГ - да простит меня Гребенщиков :) ) тем временем пригласил к себе команду DEC-овских виртуозов во главе с Дэвидом Катлером (ведущий разработчик RSX11M и VMS), дабы спасти Микрософт от позора прошлых творений. Они за один 1989 год создали ядро ОС новой технологии (сокращенно - NTOS). В основу этой ОС вошла архитектура ее предшественницы - VMS. БГ, видя положительный результат, принимает "волевое" решение "прикрутить" к ядру NT все, что было до сих пор сделано. То, что получилось, назвали Windows NT, а ее API - win32, который и стал стандартом Микрософта на веки вечные... Но, видимо, что-то там не срослось: народ, хоть и меньше, чем раньше, но все же жалуется и на 4-ю, и на 5-ю версию NT, и на еще одного мутанта, выросшего из NT - Windows XP. Вот и подхватил я девиз создателей сайта www.uzhos.tk: "сделаем ОСь, которая не падает, и работает быстрее Windows". А еще задумал заставить ее в реальном времени работать... Планируется совместимость будущей ОС с NT как на уровне драйверов, так и на уровне подсистемы win32, дабы на первых порах можно было воспользоваться "готовеньким". Но это не означает, что будет создан очередной клон windows. Попытка создания совместимой ОС чаще всего приводит к созданию жалкой пародии на оригинал (например, reactos), или концептуально устаревшей ОС, не содержащей ничего нового, какой является Linux. Наша ОС как использует проверенные временем решения, так и содержит ноу-хау решения, дающие ей ряд преимуществ по сравнению с существующими ОС. Совместимость на уровне ядра обеспечивается прослойкой совместимости, а совместимость с NT, Linux и пр. на прикладном уровне обеспечивается соответствующими подсистемами win32, Posix, Linux.

2. Расскажите про вашу команду и её структуру.
  Команда у нас пока небольшая, в списке 18 человек, но работают пока не все. Структура еще не сформировалась. Главный идеолог и архитектор - я (Семанин Сергей).

3. Какие главные концепции Уж ОС?

3.1. Жесткое реальное время.
  Предполагается сосуществование в ОС "обычных" задач с задачами жесткого реального времени. ОС поддерживает 256 приоритетов, которые разбиваются на группы "жесткого" и "мягкого" реального времени, группу обычных приоритетов(динамические приоритеты), и фиксированно низких. Планировщик ОС реализует вытесняющую многозадачность совместтно с круговым планированием.

3.2. Многозадачность, многопоточность.
  ОС поддерживает равноправное планирование потоков. Процесс - это не планируемая (исполняемая) инстанция, а общее отобращение, в котором могут существовать N потоков. Совокупность потоков, выполняемых в общем отображении, и является процессом. Поток также не является конечной исполняемой инстанцией: это контекст, в котором могут выполняться поочередно, или с вытеснением, множество задач. Например, текущая задача в любой момент может быть вытеснена, и в контексте потока "поверх" вытесненной задачи может быть выполнена APC или вложенная задача. Отложенные прерывания (DPC) выполняются на уровне потока и в контексте потока. Отложенные прерывания разбиты на 2 подгруппы по 16 приоритетов в каждой. Для исполнения отложенных прерываний выделяются потоки с приоритетами жесткого реального времени.

3.3. Модель памяти - "плоская".
  ОС поддерживает виртуальную память с двумя кольцами защиты: кольцоядра и пользователя. Память разделяется на 3 раздела: а) раздел пользователя (2 Гб), в вотором создается "плоская" память для прикладных процессов; б) общий раздел(1 Гб), В котором находятся разделяемые библиотеки и подсистемы, общие для всех процессов; в) системный раздел (1 Гб), в котором находится ядро и защищенные подсистемы режима ядра.

3.4. Архитектура ядра
  Микроядро, но не классический Mach Kernel. Микроядро включает в себя обработчики прерываний/исключений, планировщик потоков (объектов), базовые механизмы синхронизации и таймер. Микроядро "ничего не знает" о существовании менеджера памяти, системы ввода-вывода и других подсистем, позволяет создавать статические объекты базовых классов ядра, либо инициализировать динамические объекты, распределенные внешним по отношению к микроядру менеджером памяти. Микроядро предоставляет законченный API, при помощи которого можно строить приложения или прикладные подсистемы, работающие в отображении ядра, т.е. является инструментом для создания подсистем первого уровня: менеджера памяти, системы ввода-вывода, менеджера объектов для поддержки объектов высокого уровня и созданият.н. исполняющих подсистем (win32, Posix, Linux и т.п.). Большинство подсистем ядра выполняется в контексте вызывающего потока и от его имени. Концепция "подсистема - отдельный поток" будет использоваться только для создания некритичных ко времени или особо защищенных подсистем. Сами подсистемы разделяются на подсистемы ядра, защищенные подсистемы, работающие в общем для всех процессов отображении, и прикладные подсистемы. Уровень абстрагирования от аппаратуры реализован как в отдельном модуле HAL, так и в ядре. Модуль HAL содержит, кроме функций абстрагирования, функции абстрагирования семейства процессора. Например, для настройки ОС на конкретный процессор семейства Intel достаточно сменить модуль HAL. А такие модули, как планировщик и диспетчер прерываний, физически находятся в модуле микроядра.

3.5. Модульность.
  Вся ОС состоит из модулей, которые собираются в систему на этапе загрузки и конфигурирования. Заложенное требование к совместимости с NT определяет использование в качестве модулей DLL. (в частности, драйверы выполнены в виде DLL, и все импортируемые ими API - тоже DLL, экспортируются наружу тоже DLL). Модульная структура UzhOS практически совпадает со структурой NT. Но сходство - чисто внешнее. Отличие - в содержимом модулей, т.е. в реализации подсистем.

3.6. Объектная идеология.
  Базовые механизмы ядра представлены классами объектов. Структуры классов объектов реализованы на С, но совместимы с C++. Передполагается для разработки подсистем высокого уровня использовать С++. В микроядро встроен диспетчер объектов, позволяющий выполнять типовые действия, не зная о конкретных классах объектов, существующих в системе. Такое взаимодействие реализовано посредством вызовов типовых виртуальных методов управления объектами. Микроядро позволяет добавлять в систему новые интерфейсы, создавать надстройки над существующими интерфейсами, не перекомпилируя само ядро, и ничего в нем не меняя. Объектная идеология является "краеугольной" концепцией UzhOS. Кроме того, что она позволяет создать действительно модульную ОС, собираемую и конфигурируемую "из кубиков", эта идеология открываетновые возможности. Каждый объект или ресурс системы представлен интерфейсом, с которым может взаимодействовать как локальный, так и удаленный клиент. Любой пользователь может взаимодействовать с любым объектом (или ресурсом, выраженном в виде объекта). Доступ ограничивается только правами и привилегиями.

3.7. Система ввода-вывода
  Асинхронная, обеспечивающая три типовые режима ввода-вывода: с ожиданием (блокирующий), без ожидания (неблокирующий), с вызовом процедуры завершения (неблокирующий). Оповещение, соответственно, по событиям и процедурам завершения (процедура завершения - это APC, вызываемая асинхронно по отношению к потоку, в котором она вызывается. Ее можно рассматривать, как сигнальный хадлер, назначаемый индивидуально к объекту ввода-вывода). Процедура завершения может быть вызвана независимо от текущего состояния потока (заморожен, активен). Система ввода-вывода типизует интерфейсы для байт-ориентированного, потоко-ориентированного, блочно-ориентированного ввода-вывода. Доступ к периферии возможен на физическом, логическом и файловом уровне. любой носитель данных может быть ассоциирован с любой фацловой системой. Например, уже существующий в какой-либо файловой системе файл может быть объявлен носителем данных, ассигнованным к другой файловой системой. Т.е. любой файл может быть виртуальным диском, работающим в своей файловой системе.

3.8. Виртуальные терминалы
  Это текстовые или графические консоли, предоставляемые процессу. Это лишь интерфейс. Сам экран может быть как локальным, так и удаленным. Любой пользователь, зарегистрировавшийся удаленно, может вызвать на исполнение любой процесс, причем окно процесса, текстовое или графическое, будет в этом случае отображаться на удаленной машине. Объектная идеология ОС UzhOS позволяет экспортировать текстовый или графический терминал, как объект, любому удаленному компьютеру, причем компьютер необязательно должен быть UzhOS машиной, на машине клиента достаточно установить пакет поддержки динамического связывания и пакет поддержки текстового или графического терминала. Машина, с которой соединяется удаленный пользователь (сервер), предоставляет ему интерфейс доступа к системе, а машина, на которой находится пользователь (клиент), возвращает серверу интерфейс терминала.

3.8.1. Удаленные текстовые консоли.
  Удаленные текстовые консоли работают просто: они предоставляют машине сервера интерфейс для посимвольного и построчного вывода текста, управление курсором, режимом отображения, консольный ввод. Терминал визуализируется на машине клиента с использованием ее собственного локального текстового интерфейса.

3.8.2. Удаленные графические консоли.
  Графические консоли работают сложнее. Они представляют из себя графические менеджеры, локально реализующие удаленные запросы создания окон и их перерисовки, манипулирование вводом с клавиатуры и мыши. При этом при наличии у клиента и сервера общей операционной среды менеджер удаленного терминала оперирует системными иконками и фонтами, а при поддерке удаленного графического терминала в "чужой" среде необходимые средства оформления окон необходимо поставлять вместе с пакетом поддержки удаленного терминала, либо импортировать их из машины сервера.

3.8.3. Графические интерфейсы.
  Поддержка качественных графических интерфейсов для управления системой во многом зависит от качества поддерживаемой графики. Не вдаваясь в технические детали системной поддержки графики, можно сказать, что UzhOS будет раполагать достаточной поддержкой для реализации как двухмерных, так и трехмерных оконных интерфейсов. Для поддержки компьютеров с дешевыми графическими интерфейсными картами можно ограничиться простым оформлением системных панелей (от панелей, работающих в EGA - VGA режимах, до двухмерных панелей с расширенными графическими режимами), а для мощных компьютеров с мощными графическими интерфейсными картами можно предлагать темы оформления, включающие трехмерные панели.

4. На какой стадии проект?
  Проект находится на стадии разработки ядра. Начали разработку с семейства интел, базовой является реализация I486, впоследствии будет реализована поддержка 386-686. Механизмы MP закладываются сейчас, но реализованы будут вместе с поддержкой 586. Уже реализованы загрузчик, базовые механизмы микроядра (диспетчер прерываний - планировщик - диспетчер объектов, базовые процедуры управления), HAL - неполностью. Потоки ядра уже работают, контексты переключаются. Сейчас разрабатываются объекты синхронизации. Семафоры уже работают.

5. Можно узнать о ближайшем to-do в плане реализации?
  Очередь за мьютексами, событиями, кластерами двоичных флагов, таймером. Как только это будет сделано, можно объявить о том, что нижний уровень ОС запущен, и приступать к реализации подсистем: менеджера памяти, системы ввода вывода. Параллельно запуску системы ввода - минимальный Plug-n-Play: конфигурация драйвера диска, детектирование файловых томов. Для использования "готовых" драйверов NT уже на этом этапе придется программировать прослойку совместимости с NT.

6. Кого вы видите конкурентами на ближайшем фронте?
  Пока не будет запущено ядро и система ввода-вывода, говорить о какой-то конкуренции не приходится. Но как только мы сможем представить 1-е, 2-е + сеть (TCP/IP), мы уже можем потеснить кое-кого на рынке embedded: по крайней мере, по техничеким хараетеристикам и возможностям реального времени UzhOS будет далеко впереди QNX и VxWorks.

7. Инструментарий разработки.
  Для разработки был выбран Mingw (GCC + навороты винды): т.к. он предоставляет поддержку разных платформ, это - решающий аргумент (не покупть же у Микрософта компиляторы для разных платформ). Mingw позволяет компилировать и линковать DLL, драйверы и windows приложения, а это как раз то, что нам нужно. Ассемблер, соответственно, At&T. Это неплохой ассемблер, в свое время заимствован у DEC (ассемблер для PDP11, впоследствии добавлен синтаксис VAX). Есть небольшие отличия от упомянутых в синтаксисе, мощнейший арсенал макросов последних версий ассемблеров DEC практически не реализован, чтобы не было соблазна все на ассемблере писать :).

8. Расскажите о процессе загрузки УжОС
  Загрузчик реализован в виде "многоступенчатой космической ракеты": запускается целиком, а использованные куски по дороге отваливаются. Специальной утилитой из модулей, необходимых на первом этапе загрузки, создается модуль особого формата, напоминающего простую файловую систему: вначале - справочник содержащий имена, смещения и размер модулей, за ним, собственно, модули:
  1. Вторичный загрузчик - модуль, состоящий из 16-разрядной секции, производящей инициализацию и чтение необходимых параметров из BIOS, старт защищенного режима; 32-разрядной секции, инициализирующей страничный каталог и таблицы, включающий страничный режим и загружающий PE модуль системного загрузчика.
  2. Модуль системного загрузчика - PE EXE, довершает инициализацию процессора, загружает и перемещает модули микроядра, HAL (в дальнейшем также модули подсистем менеджера памяти, ввода-вывода и базовые драйверы - драйвер диска и файловой системы). Точное содержимое загрузочного модуля определяется при инсталляции системы (или ручным конфигурированием). Затем инициализирует необходимые структуры HAL и микроядра: подготавливает карту памяти страничного режима, инициализирует каталог и таблицы в отображении ядра, структуры ядра, процессора и т.д. и т.п. Затем стартует системный поток, который завершает загрузку. На этом этапе запускается менеджер памяти, система ввода-вывода, драйвер системного диска и файловая система. Все остальное грузится с диска.
  3. Собственно, модули, необходимые на первом этапе загрузки: kernel.exe, hal.dll, mm.dll, iosys.dll, fsXXXX.dll, disk.sys. и т.п.
Модуль загрузки находится в корневом каталоге системного диска, как непрерывный файл, и грузится из бут-сектора целиком. В случае, если бут-сектор не может загрузить целый файл, он грузит вторую ступень из тела 16-разрядной секции, которая довершает загрузку.