Подходы к проектированию Ядра Операционной Системы
Эта статья повторяет тезисы, изложенные на конференции Warpstock Europe 2005. Но там я говорил только о небольшой части общей идеи - той, которая связана с OS/2, учитывая тематику конференции. На самом деле идея гораздо более общая, и OS/2 в этом проекте только пример применения идей, которые могут быть применены к различным OS.
Есть мысли о создании современной операционной системы с рабочим названием - OS/21. Система должна быть высоконадежной,отказоустойчивой, легко расширяемой и модифицируемой, в том числе и с целью переноса на разные платформы.
В качестве основы была выбрана микроядерная операционная система K42.
Почему не L4? В основном потому, что L4 - это микроядро, к которому нужно еще написать чертову уйму обвязок - серверов, а K42 - это основанная на микроядре операционная система, в которой все эти серверы уже имеются. Кроме того, K42 - это, по сути, конструктор, специально предназначенный для создания на его основе различных ОС. Да и свойства у K42 весьма приятные - от принципов управления аппаратными ресурсами до встроенной поддержки вычислительных кластеров и до возможности прикладной программе динамически заменять предоставляемые ей операционкой серверы своими собственными. Причем затронет это только эту программу и никого больше. Но выбор K42 в моем проекте не обязательный - если окажется, что что-то другое подходит лучше - оно и будет использовано.
Главное в проекте - идеи. Я же архитектор, в конце концов :-) Основной концепцией подхода к проектированию ядра, вокруг которой все крутится, является ресурс. Ресурсом является все, с чем имеет дело какая-либо программа: массив памяти, порты ввода-вывода, линии прерывания и ПДП, а также любые другие аппаратные средства, которые могут появиться в будущем, каналы поступления информации, дисковые накопители и разделы на них, а также тома, созданные из этих разделов, и так далее, заканчивая перечень, скажем, окнами пользовательского интерфейса. Все известные системе типы ресурсов имеют идентификаторы - 64 разрядное целое число. Этого количества должно хватить на все случаи жизни. Ресурс каждого типа обслуживается драйвером, ответственным за этот тип. В процессе выполнения запроса драйвер, естественно, может обращаться к драйверам ресурсов более низкого уровня: скажем, драйвер логического диска вызывает драйвер файловой системы, тот для чтения-записи секторов вызывает драйвер тома, тот в свою очередь - драйвер диска (контроллера) и так далее.
Каждый драйвер может быть запущен, остановлен или заменен в любой момент, без остановки или перезагрузки операционной системы. Если происходит обращение к ресурсу, драйвер которого в данный момент не запущен, этот драйвер запускается автоматически, если это разрешено в настройках системы. Все ресурсы являются именованными в духе UNC: \\машина\имя ресурса\<строка, специфичная для данного типа ресурсов>. Это необходимо в том числе и для поддержки кластеризации. Таким образом любой ресурс, даже память, вовсе не обязан быть физически расположен на той машине, где выполняется приложение.
В силу изложенных особенностей, система автоматически получается многопользовательской, поэтому присутствует и система разграничения прав пользователей.
На архитектуру K42 все это ложится очень хорошо. А при чем здесь OS/2? Да почти что ни при чем. Просто с точки зрения любой программы операционная система - это набор функций, которые она может вызвать (API). Если реализовать уникальный ни с чем не совместимый API, то мы получим ОС, к которой нет ни одной прикладной программы и ни одного драйвера. Если же дополнительно к своему внутреннему реализовать еще и API какой-то популярной ОС, то мы сразу получаем кучу полезных приложений. В K42 как пример имеетются две подсистемы. Одна позволяет использовать драйверы Linux, другая - никак не связанная с предыдущей - подсистема, позволяет запускать программы Linux. Аналогично и параллельно с ней можно реализовать подсистему для запуска программ OS/2.
Естественно, поскольку новая ОС будет обладать большими возможностями, у нее будут и свои собственные функции, но они будут дополнением к заимствованным, а эти заимстсвованные при этом будут ничуть не менее родными.
Если мы постановим в точности воспроизводить OS/2, то нам придется воспроизводить и особенности работы ее планировщика. Сильно вмешиваться в микроядро K42 для этого нее придется - там все сделано для легкости такого вмешательства. Более того, в его нынешнем планировщике есть и задачи, и потоки. Некоторая разница только в принципе планирования: в OS/2 единицей планирования является поток, которому непосредственно ядром и выделяется квант времени, а в K42 планирование двухступенчатое - ядро выделяет время задаче - назовем это мегаквантом, а вторая часть планировщика, которая живет уже в user level, выделяет части этого мегакванта потокам задачи.
И я не уверен, что для задач реального времени этот вариант хуже, чем осевый. К тому же разработкой K42 занимается IBM, а уж они в планировщиках толк знают.
Но, как я уже сказал, все можно изменить. Особенно с учетом того, что для изменения того, что мне в K42 не нравится, всю ее потребуется переделывать: оставить только принципы и алгоритмы, но начисто изменить код. Это я уже отношу к разряду "о плохом". С другой стороны, в процессе запланированного переписывания от K42 не останется ни одной строчки исходного кода, а это позволяет не заботиться, под какой она там лицензией идет. А размер исходников K42 довольно скромный - в несколько раз меньше, чем одни только заголовочные файлы в осевом тулките.
Автор: Юрий Пронякин,
Технический редактор: Игорь Васьков
Полезные ссылки:
Интересные ссылки: Услуги юриста адвокат стоимость услуг гражданских и уголовных адвокатов.
Комментариев к странице: 0 | Добавить комментарий
Домой | Проект ядро Core/2 | Проект OS/4 Download | Новости | Гостевая книга | Подробно обо всем | Нужные программы | Проекты | OS/2 FAQ | Всячина | За и Против | Металлолом | #OS2Russian | RDM/2 | Весёлые картинки | Наша галерея | Доска объявлений | Карта сайта | ПОИСК | ФОРУМ