Архитектура и принципы построения операционной среды «мини-ОС»

Ю.Фонин, С.Грассман
Труды Института Системного Программирования РАН, 2004 г.

Концепция разработки мини-ОС

При разработке минимальной операционной системы (далее мини-ОС) к ней выдвигались следующие требования:

Портируемость – время на адаптацию системы к новой архитектуре должно быть минимально. Количество платформенно-зависимых частей мини-ОС должно быть минимально и их наличие должно обуславливаться только невозможностью реализации в платформенно-независимом виде.

Програмный интерфейс мини-ОС должен быть совместим с интерфейсом ОС Windows.

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

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

Для уменьшения времени портирования мини-ОС использовались следующие методы: Разделение платформенно-зависимых и платформенно-независимых частей ОС. Реализация платформенно-зависимых частей в виде макросов. Использование инлайн-ассемблера.

Формализация функциональности платформенно-зависимых частей ядра.

Поддержка многопроцессорной системы с общей памятью.

Совместимость с ОС Windows достигнута за счет использования интерфесов функций, а также имен типов данных Windows при декларации объектов ОС, таких как поток, синхронизационный примитив и т.д.

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

Далее производится портирование операционной среды на аппаратную платформу, адаптированную под данное приложение. Тестирование мини-ОС выполняется с помощью специального набора тестовых приложений.

Производится компиляция приложения совместно с мини-ОС под целевую платформу и выполняется оценка производительности полученной системы.

Наконец, осуществляется оптимизация приложения и операционной системы. При необходимости производится модификация аппаратной платформы и соответствующих платформенно-зависимых частей ОС.

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

Литература

[1] Wind River Systems, Inc., “VxWorks 5.4”, available at http://www.windriver.com/products/device_technologies/os/vxworks5/.

[2] RTEMS available at http://www.rtems.com

[3] Eonic Systems, Inc., “Virtuoso v.4.1”, available at http://www.eonic.com/.

[4] EUROS documentation and manuals are available at http://www.kaneff.de/

[5] A Case for Nano-Kernels. See-Mong Tan, David K. Raila, Roy H. Campbell

Department of Computer Science University of Illinois at Urbana Champaign 1304 W. Springfiel Urbana, IL 61801

[6] A Pattern Language for Porting Micro-kernels. Michel de Champlain Departament of Computer Science, University of Canterbury, Christchurch, New Seland.

[7] WLAN 802.11 available at http://grouper.ieee.org/groups/802/11/

Портирование мини-ОС

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

Далее мы рассмотрим набор платформенно-зависимых макросов для каждого из модулей, перечисленных в разд. 3. Заметим, что реализация любого макроса требуется только в том случае, если модуль, использущий данный макрос, применяется в требуемой конфигурации.

Платформенно-зависимая часть модуля управления потоками включает в себя следующие макросы: сохранение контекста,

восстановление контекста,

сохранение указателя контекста

загрузка указателя контекста.

Для реализации данных макросов необходима следующая информация: Структура контекста, т.е. список регисров, которые отражают состояние процесса в момент прерывания потока.

Указатель контекста – регистр, содержащий адрес, по которому сохраняется контекст.

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

Для портирования модуля динамического распределения памяти требуется определение следующих констант: MMU_START_ADDR – начальный адрес динамической памяти

MMU_WORD_SIZE – размер ячейки памяти, соответствующей единичному адресу в байтах

MMU_PAGE_SIZE – размер страницы памяти в байтах

MMU_NUM_PAGES – число страниц памяти, изначально доступных для динамического выделения.

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

Для портирования модуля управления прерываниями на новую платформу необходимо реализовать следующие макросы: DISABLE_ALL_IRQS() – запрещает обработку всех маскируемых прерываний.

ENABLE_ALL_IRQS() – разрешает обработку маскируемых прерываний.

ENABLE_IRQ_N()/DISABLE_IRQ_N() – запрещает/разрешает обработку прерывания N.

SET_PRIOR_IRQ_N(prior) – устанавливает приоритет прерывания N, если имеется программируемая система приоритетов.

Для реализации этих макросов требуется следующая информация: флаг «запретить все прерывания», запрещающий все прерывания в системе;

таблица векторов прерываний;

таблица приоритетов прерываний;

для каждого прерывания:

флаг, запрещающий прерывание;

приоритет прерывания или адрес ячейки, содержащий приоритет прерывания.

Для портирования модуля синхронизационных примитивов для многопроцессорной системы требуется реализации макроса SYNC_SWAP(addr, read_val, send_val), который считывает из ячейки памяти по адресу addr значение переменной read_val и записывает значение send_val в ту же ячейку. Ключевым моментом, зависящим от особенностей целевой аппаратной платформы, является то, что в течение всего цикла чтения/записи никакой другой процессор или периферийное устройство не должны получить доступ к данной ячейке. Кроме того, требуется определение следующих констант:

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

Портирование мини-ОС на платформу ARM7TDMI

В качестве аппаратной архитектуры для отладки и тестирования были использованы две системы:

1. Однопроцессорная система на базе процессора ARM7TDMI

2. Архитектура ARM_MUSIC, состоящая из 32-х процессоров ARM7, общей памяти и специальной памяти синхронизации.

В качестве приложения использовалась многопоточная реализация протокола WLAN 802.11 [7], а также набор специальных тестов для проверки корректной работы каждого отдельного модуля ОС.

Для портирования мини-ОС был использован следующий сценарий:

Портирование модуля динамической памяти.

Портирование планировщика задач с программно-управляемым вызовом планировщика (вызов планировщика осуществлялся с помощью функции Sleep())

Портирование синхронизационных примитивов (однопроцессорная система)

Переход на многопроцессорную систему. Реализация макроса SYN_SWAP().

Реализация драйвера таймера. Вызов планировщика по прерыванию таймера.

Портирование приложения WLAN, совместная компиляция WLAN и мини-ОС.

Сумарное время портирования операционной среды составило 6 человко-дней. Для сравнения, портирование операционной среды EUROS в минимальной конфигурации требует минимум один человеко-месяц.

Структура мини-ОС

Ядро мини-ОС состоит из следующих модулей: Модуль управления потоками (Task manager)– включает в себя планировщик потоков, а также набор функций для управления состоянием потока. Планировщик задач реализован в виде функции, осуществляющей выбор активного потока и переключение контекста.

Модуль динамического распределения памяти (Memory manager) – содержит функции для динамического распределения памяти. Пользователю предоставляются две функции: alloc() для выделения памяти данного размера и free() для освобождения выделенной памяти.

Модуль синхронизационных примитивов (Synchronization primitives) – включает в себя функции для создания синхронизационных объектов и управления синхронизационными примитивами: семафоры, мьютексы, бинарные события.

Модуль управления прерываниями (Interrupt controller)– представляет собой набор функций для управления состоянием системы прерываний и функцию для инсталляции обработчиков прерываний.

Модуль ввода-вывода (IO manager) – предоставляет унифицированный интерфейс для доступа к устройствам ввода-вывода.

Модуль начальной загрузки – инициализирует регистры процессора, а также структуры и модули операционной системы. Он инициализирует главную задачу (функция main) и запускает её.

Рис 1. Базовая структура мини-ОС

Для каждого из модулей имеются несколько реализаций в зависимости от конфигурации операционной системы. На Рис 1. представлена базовая структура мини-ОС. Прерывистыми линиями обозначены так называемые «относительные зависимости», то есть, если один модуль включен в систему, то другой использует функции зависимого модуля. В противном случае используется реализация модуля без использования зависимого модуля.

В качестве примера рассмотрим зависимость модуля синхронизационного примитива от модуля управления потоками. Если ОС сконфигурирована как однозадачная, то применяется простой опрос объекта синхронизации. В том случае, когда используется многозадачность, при переходе в режим ожидания сигнала вызывается функция Sleep(), которая переводит текущую задачу в так называемый «спящий» режим и вызывает планировщик задач. При соответствующем изменении состояния объекта синхронизации для «спящей» задачи, вызывается функция Resume(), которая переводит ожидающую задачу в активный режим.

В минимальной конфигурации мини-ОС может состоять только из блока начальной загрузки, которая инициализирует процессор и передает управление main-функции приложения. Все остальные модули подключаются к системе в соответствии с заданной конфигурацией.

В настоящей статье описаны принципы

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