Lumber room
September 2008 28

Управляемая операционная система Вы говорите? Дайте мне парочку…

Типичная ошибка разработчиков


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

О разработке операционных систем: современные реалии.


Грубо говоря, бывают монолитные ядра и микроядра. В первых весь ввод-вывод, управление процессами и многие основные драйвера находятся внутри одного большого процесса. Вторые разносят решение этих задач по отдельным небольшим модулям.

В то время как вторые предоставляют как минимум одно очевидное преимущество, заключающееся в лучшей стабильности (умерший модуль можно заменить), на практике Linux и Windows используют монолитные ядра. Почему? Их проще реализовать.


Собственно, я знаю только 3 микроядра: Mach ядро MacOS X, ядро L4 и ядро ОС Minix, написанное небезызвестным Эндрю Таненбаумом.

Хотя самая распространённая ОС, Windows, по-прежнему имеет внутри себя монолит, ребята из Microsoft уже давно занимаются разработкой совершенно нового ядра.

Singularity


Ещё в давнем 20хх-ом году, когда C# и .NET только-только набирали обороты, меня заняла идея попробовать написать операционную систему на управляемом коде. Однако в то время эта мысль так и осталась мыслью. Каково же было моё удивление, когда год спустя я увидел на сайте Microsoft Research страничку, посвящённую разработке новой ОС. Они решили применить преимущества управляемого кода к разработке операционной системы. Так появился проект Singularity.

Управляемый код


С переходом на управляемый код мы получаем одно огромное преимущество: мы можем проконтролировать программу ещё до того, как она начала выполняться. Что из этого можно извлечь?

Свойство всего управляемого кода: программист не может совершить ошибку в работе с памятью. А это означает, что пока мы уверены в компиляторе нашего промежуточного кода, мы так же можем быть уверенны, что наши программы не содержат в себе уязвимостей типа переполение буфера (самая распространённая критическая уязвимость), не пишут по ошибке в чужую память и не читают данных по висящим указателям. Сборщик мусора берёт на себя нелёгкую ношу управления памятью программы (пока правда с некоторыми потерями производительности).

Мы можем положиться на статический анализ программы, таким образом избавившись от необходимости в аппаратной защите памяти. Для простейших процессоров это означает, что наконец можно спокойно запустить многозадачную ОС и не бояться, что программы поубивают друг друга. Для современных процессоров линейки x86 это даёт возможность запускать все программы в режие ядра, что снимает накладные расходы на переключение из одного режима в другой при каждом системном вызове.

Мы можем добавить иные правила практически произвольной сложности и проверять, удовлетворяет ли программа им перед её запуском, а не при каждом обращении к ресурсу, как это делается во многих случаях в существующих ОС.

Singularity объединяет в себе все эти преимущества. В качестве виртуальной машины Microsoft по понятным причинам использовала собственную реализацию Common Language Infrastructure. Процессы ОС могут все работать в режиме ядра, оставаясь защищёнными друг от друга. Драйвера получают API и расширенные возможности, основанные на котрактах. А программист может писать свои программы на любом .NET совместимом языке.

Открытые проекты


Microsoft — это одна часть мира. Рядовой программист — другая. Да, выложен Singularity RDK, но непосредственно в разработке ОС компания вряд ли даст возможность поучавствовать.

Идея распространилась. В сообществе открытого ПО появились свои наработки. Cosmos и SharpOS. Для первого я даже написал не один десяток строк (в основном трансляция MSIL'а в ассемблерный код).

Обе эти разработки существуют уже довольно долгое время. Однако некоторые вещи заставили меня отказаться от усердного участия в этих проектах.

Во-первых, ни один из них до сих пор не реализовал самой важной вещи: сборщика мусора. Поэтому код Cosmos'а и SharpOS'а фактически не является управляемым.

Во-вторых, ни один из проектов не идёт по тому пути, который кажется мне более правильным — разработка от самого низкого уровня к самому высокому, от ядра и компилятора к драйверам и пользовательским программам. В Cosmos'е уже есть код для работы с Ethernet, но нет JIT компилятора и таких важных понятий ОС как процесс и поток.

Виртуальная машина своими руками?


Учиться и практиковаться. Как студенту кафедры системного программирования, мне весьма интересно попрактиковаться в написании компилятора и/или ОС. А заодно разобраться в чём-нибудь новом.

В качестве языка выбран F#, целевая архитектура — AMD64 (писать под неё несколько проще, чем под обычный x86). Сегодня днём (после пары месяцев нерегулярного программирования в свободное время) я-таки умудрился скомпилировать простейшую функцию (n-ный член последовательности Фибоначчи) своим транслятором MSIL -> AMD64 binary. Сгенерированный код пока неверный ( :) ), т.к. некоторые вещи ещё не доделаны, но уже достаточно близок к тому, что нужно.

Заключение


Очень надеюсь, что SharpOS и/или Cosmos в конце концов станут полноценными операционными системами (не из числа аутсайдеров) и что мои собственные наработки примут участие в гонке управляемых технологий.

P.S. Join OS community!
+43
567 3
Comments 43
Top of the day