RT-Linux

RT-Linux – это операционная система, в которой небольшое ядро реального времени сосуществует с Posix-like ядром Linux. Основная цель – сделать доступными сложные службы и оптимизированное поведение системы в стандартных ситуациях для системы с разделением времени и в то же время выполнять задачи реального времени. В прошлом операционные системы реального времени примитивны – простые программы, которые предлагали пользователю чуть больше, чем просто библиотеку основных функций. Но в наше время пользователи требуют доступ к TCP/IP, графическому дисплею и системе окон, базам данных и другим службам, которые не являются ни примитивными, ни простыми. Одно из решений – добавить non-real-time службы к базовому ядру реального времени, что и было проделано в VxWorks и немного по-другому в микроядре QNX. Вторая возможность модифицировать стандартное ядро и сделать его полностью прерываемым.

RT-Linux организован третьим способом, в котором простое ядро реального времени запускает обычное ядро как одну из задач реального времени с самым низким приоритетом, используя виртуальную машину для того, чтобы сделать стандартное ядро полностью прерываемым.

В RT-Linux все прерывания обслуживаются ядром реального времени, а затем передаются стандартному ядру, но только в том случае, если нет необходимости запускать одну из задач реального времени. Для того чтобы минимизировать количество изменений в стандартном ядре, этот механизм реализован при помощи эмулирования ICH (Interrupt Control Hardware). Ядро реального времени и пользовательские задачи Linux могут обмениваться данными через неблокируемые очереди и сегменты разделяемой памяти.

С точки зрения программиста очереди выглядят как стандартные последовательные устройства UNIX, доступ к которым возможен при помощи системных вызовов POSIX read/write/open/ioctl. Разделяемая память доступна через системный вызов mmap.

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

Программа реального времени состоит из двух частей: задачи, которая представляет собой модуль ядра и обыкновенного UNIX/Linux процесса, который заботится об обработке данных, доступу к дисплею и сети, и о любых других функциях, не требующих таких жестких временных рамок.

На практике оказалось, что идея RT-Linux очень удачна. В самом худшем случае запаздывание прерываний на 486/33MHz PC оказалось менее 30 мкс, что близко к аппаратному пределу. Для прикладных задач симбиоз систем реального времени и оптимизированной для «общего случая» оказался очень удачным. Наиболее часто используемая конфигурация RT-Linux – примитивные задачи реального времени со статически распределяемой памятью без ее защиты, простым планировщиком с фиксированными приоритетами без защиты от нереализуемых планов, аппаратным запрещением прерываний; разделяемая память – единственный механизм синхронизации задач реального времени, ограниченный набором операций над FIFO-очередями, подсоединенными к обычным процессам Linux.

Ядро Linux позволяет в динамике загружать и выгружать модули ядра, сделав отдельные части ядра реального времени в виде модулей, легко изменять ядро реального времени. Уже написаны альтернативные планировщики и модуль семафоров. Во время работы системы можно загрузить модуль с задачами реального времени, затем выгрузить стандартный планировщик и загрузить, например, EDF планировщик. Можно пробовать разные комбинации модулей, пока не будет найдена оптимальная.

Этот вариант Linux позволяет выполнять задачи в реальном времени. Это достигается путем вставки ядра реального времени между стандартным ядром Linux и аппаратными прерываниями и позволяет избавиться от главной причины непригодности Linux для задач реального времени – большого запаздывания прерываний.

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

Простые очереди FIFO реализованы для обмена данными между процессами реального времени и процессами Linux. Типичное приложение состоит из двух частей – задачи реального времени, непосредственно работающей с аппаратурой, и обыкновенной задачи Linux, которая выполняет остальные операции, такие как сохранение данных на диск, пересылка их по сети, работа с пользователем (GUI) и т. д.

Самый короткий период для периодически вызываемых задач реального времени в RT-Linux на Pentium 120 – менее 150 мкс. Задачи, вызываемые по прерыванию, могут иметь намного меньший период.

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

Необходимо отметить, что компания LynuxWorks начала поставки (17.05.2002) встраиваемой ОС BlueCat Linux для комплекта разработчика ПО Intel Internet Exchange Architecture Software Developers Kit (Intel IXA SDK) 2.0, предназначенного для семейства сетевых процессоров Intel IXP1200. ОС BlueCat Linux распространяется бесплатно совместно с Intel IXA SDK 2.0.

Vx Works давно стала де-факто стандартом для подавляющего большинства систем, использующих встроенные ОС. Флэш-память вычислительной системы IXP1200 содержит загрузчик ядра VxWorks. Для разработчиков это упрощает задачу написания новых программ. Кроме того, уже реализована возможность работы сетевого процессора под управлением ОС Linux (с расширениями реального времени). Осуществляется программная поддержка некоторыми производителями ОС Linux (HanpHMep, LynuxWorks и т. д.).

RTEMS

RTEMS (Real-Time Executive for Multiprocessor Systems) – это некоммерческая операционная система реального времени для глубоко встраиваемых систем [101]. Разработчик системы – компания OAR (On-Line Applications Research Corporation, США). Система была создана по заказу министерства обороны США для использования в системах управления ракетными комплексами. Система разрабатывается для многопроцессорных систем на основе открытого исходного кода в противовес аналогичным системам с закрытым кодом. Система рассчитана на платформы MS-Windows и Unix (GNU/Linux, FreeBSD, Solaris, MacOS X).

Ядро RTEMS обеспечивает базовую функциональность систем реального времени. В эти возможности входят

· мультизадачная обработка;

· работа в гомогенных и гетерогенных системах;

· планирование, управляемое событиями, на основе приоритетов;

· планирование с монотонной скоростью;

· взаимодействие задач и синхронизация;

· приоритетное наследование;

· управление ответным прерыванием;

· распределение динамической памяти;

· конфигурирование системы для уполномоченных пользователей;

· переносимость на многие целевые платформы.

Ядро RTEMS отвечает за управление основной памятью компьютера и виртуальной памятью выполняемых процессов, за управление процессором и планирование распределения процессорных ресурсов между совместно выполняемыми процессами, за управление внешними устройствами и, наконец, за обеспечение базовых средств синхронизации и взаимодействия процессов. При этом ядро использует соответствующие менеджеры. В состав RTEMS входит набор следующих менеджеров: инициализации, задач, прерываний, часов реального времени, таймера, семафоров, сообщений, событий, сигналов, разделов, регионов, двухпортовой памяти, ввода/вывода, неисправимых ошибок, монотонной частоты, расширений пользователя, многопроцессорности. Привязка ОСРВ к аппаратуре производится с помощью специальной библиотеки подпрограмм BSP (board support package) и специализированных подпрограмм для различных архитектур. В состав BSP входят программа инициализации аппаратуры и драйверы устройств. Поддержка в RTEMS мультипроцессорных систем позволяет использовать ее для управления как однородными, так и неоднородными системами. Ядро RTEMS автоматически учитывает различия в архитектуре используемых процессоров, выполняя в случае необходимости перестановку байтов и другие процедуры. Это позволяет осуществлять переход на другое семейство процессоров без значительных изменений системы.

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

В ОСРВ RTEMS реализуются следующие виды межпроцессорного взаимодействия:

· обмен данными между задачами;

· обмен данными между задачами и программами обработки прерываний;

· синхронизация между задачами;

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

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

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

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

Менеджер сообщений. Служит для обмена между задачами сообщениями переменной длины. Сообщения передаются через очереди типа FIFO («первым пришёл, первым обслужен»). Имеется возможность посылки срочного сообщения. Для каждой очереди задается максимальная длина сообщения. Сообщения могут использоваться для синхронизации задач. Задача может ожидать прихода определенного сообщения или проверять наличие сообщения в очереди.

Менеджер сигналов. Используется для асинхронного взаимодействия между задачами. Задача может включать в себя процедуру обработки асинхронного сигнала, которой передается управление при получении сигнала. Флаг сигнала используется задачей для того, чтобы проинформировать другую задачу о возникновении нештатной ситуации. Каждой задаче соответствуют 32 флага сигналов. Совокупность одного или более флагов называется набором сигналов.

Менеджер задач. Обеспечивает полный набор функций для создания, удаления и управления задачами. С точки зрения RTEMS, задачей является наименьшая последовательность команд, которая может самостоятельно конкурировать за использование системных ресурсов. Каждой задаче соответствует блок контроля задачи TCB (Task Control Block). Этот блок является структурой, которая содержит всю информацию, относящуюся к выполнению задачи. В процессе инициализации RTEMS выделяет TCB для каждой задачи, имеющейся в системе. Элементы TCB изменяются в соответствии с системными вызовами, которые выполняются приложением в ответ на внешние запросы. Блок TCB – это единственная внутренняя структура данных RTEMS, доступная приложению через дополнительные процедуры пользователя. При переключении задач в TCB сохраняется контекст задачи. При возвращении управления задаче ее контекст восстанавливается. При перезапуске задачи исходный контекст задачи восстанавливается в соответствии со стартовым контекстом, хранящемся в TCB. Задача может находиться в одном из пяти состояний: выполнение; готовность к выполнению (управление может быть передано задаче); остановка (задача заблокирована); спящий режим (созданная, но не запущенная задача); отсутствие задачи (задача не создана или удалена).

Ядро реального времени RTEMS поддерживает 255 уровней приоритетов. Чем больше значение приоритета, тем более привилегированной является задача. Количество задач, имеющих одинаковый приоритет, не ограничено. Каждая задача всегда имеет какой-либо уровень приоритета, начальное значение которого присваивается при создании задачи и в дальнейшем может быть изменено. Режим выполнения задачи определяется следующими параметрами: вытесняемость; обработка асинхронных запросов ASR (Asynchronous Signal Request); квантование времени; уровень прерывания. Эти параметры используются для распределения процессорного времени и изменения контекста задачи. Они задаются пользователем при компиляции системы.

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

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

Параметр обработки асинхронных сигналов (запросов) ASR определяет порядок обработки получаемых задачей сигналов (запросов). Если он включен, то посланные задаче сигналы будут обработаны, если выключен – сигналы будут обработаны только после включения этого параметра. Данный параметр влияет только на задачи, имеющие процедуры обработки внешних сигналов.

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

Менеджер инициализации. Отвечает за запуск и остановку RTEMS. Инициализация RTEMS производится путем создания и запуска всех инициализирующих задач и инициализирующих процедур для каждого драйвера. В случае мультипроцессорной системы происходит также инициализация механизмов межпроцессорного взаимодействия. Инициализирующие задачи отличаются от остальных задач тем, что они присутствуют в таблице инициализирующих задач пользователя и автоматически создаются RTEMS в процессе инициализации. Чтобы эти задачи выполнялись до запуска остальных задач, они должны иметь более высокий приоритет. После окончания инициализации RTEMS не удаляет инициализирующие задачи, поэтому такие задачи должны либо сами удалить себя, либо трансформироваться в «обычную» задачу. В любой системе должна быть, как минимум, одна инициализирующая задача.

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

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

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

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

Менеджер доступа к памяти. Для работы с памятью служат менеджеры разделов и регионов. Раздел – это область памяти, состоящая из буферов фиксированной длины. Каждый из этих буферов может быть выделен для использования с помощью директив менеджера разделов. Регион – это область памяти переменной длины, кратной размеру страницы для данного региона. Раздел представляет собой список буферов. При запросе на выделение буфера он выделяется из начала списка свободных буферов. Когда буфер освобождается, он помещается в конец этого списка. Регион состоит из блоков памяти различного размера, который кратен размеру страницы для данного региона. При поступлении запроса на выделение блока памяти размер запрошенного блока округляется до целого количества страниц, и при наличии свободного блока соответствующего размера этот блок выделяется. Менеджер доступа к памяти реализует следующий набор функций: создание, удаление, установка значений, освобождение, захват областей регионов/разделов и буферов, содержащихся в них. Для регионов реализуется возможность добавления памяти.

Менеджер таймеров обеспечивает работу с таймерами: создание и удаление таймеров, доступ к таймерам, запуск подпрограмм по событию/сигналу от таймера. Этот менеджер может быть использован для создания сторожевого таймера.

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

RTEMS не поддерживает динамическую загрузку приложений и модулей, поэтому сферой ее применения являются встраиваемые системы, в которых не предполагается частая модификация программного обеспечения. ОСРВ RTEMS обеспечивает достаточно слабую поддержку файловых систем, что ограничивает область ее возможного применения в сфере систем централизованного сбора и хранения данных стандартными высокоуровневыми средствами. На настоящий момент RTEMS поддерживает только файловые системы IMFS и TFTP, что явно недостаточно. Поэтому для создания на базе RTEMS файл-серверов требуется разработка специального протокола. Понимая эту проблему, разработчики RTEMS ведут активную работу по реализации систем поддержки широко используемых файловых систем (в первую очередь сетевых). В RTEMS фактически отсутствуют резидентные средства отладки. Имеются только стандартные функции rtems_panic и printf, которые позволяют выводить отладочную информацию на терминал в процессе работы системы. Следует, однако, отметить, что наличие мощных средств кросс-разработки делает этот недостаток не очень существенным.