3.2. Архитектура операционной системы qnx Neutrino

ОС QNX Neutrino строится на основе компактного микроядра, способного управлять группой взаимодействующих процессов. Как видно на рис.39 структура операционной системы больше представляет собой равноправных «игроков» взаимодействуют в ней между собой посредством координирующего ядра, чем иерархию.

ОС QNX Neutrino действует как своего рода «программная шина», позволяющая динамически присоединять/ отсоединять модули ОС по мере необходимости.

Ядро- это сердце любой операционной системы. В некоторых системах «ядро» несет столько функций, что оно уже само по себе является целой операционной системой [15]. Но микроядро в ОС QNX Neutrino – это истинное ядро, потому что, во-первых, как и ядро исполнительного модуля реального времени, оно очень компактного, а во-вторых, оно предназначено для выполнения только нескольких базовых функций:

• управление потоками (thread services) посредством POSIX- примитивов для создания потоков;

• управления сигналами (signal services) посредством примитивов сигналов;

• обмен сообщениями (message-passing services) , с помощью которого микроядро выполняет трассировку всех сообщений, пересылаемых между всеми потоками внутри системы;

• синхронизация (synchronization serviсes) посредством примитивов синхронизации потоков;

• планирование (scheduling services), с помощью которого микроядро осуществляет планирование потоков в реальном времени на основе различных алгоритмов;

• управление таймерами (timer services) , помощью которого микроядро обеспечивает большой набор POSIX- таймеров;

• управление процессами (process management services), выполняемое администратором процессов, вместе с которым ядро образует единый модуль procnto. Администратор процессов предназначен для управления процессами, памятью и пространством имен путей (pathname space).

Рис.39 Архитектура ОС QNX Neutrino

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

Все службы ОС, за исключением тех, которые выполняются обязательным модулем микроядра/администратора процессов (procnto), обрабатываются посредством стандартных процессов в пользовательском режиме. Система может содержать следующие компоненты:

• Администраторы файловых систем;

• Администраторы устройств символьного ввода/вывода;

• Графический пользовательский интерфейс (Photon);

• Сетевой администратор;

• Стек протоколов TCP/IP.

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

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

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

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

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

Драйверы устройств позволяют ОС и прикладным программам согласованно использовать базовое оборудование компьютера (например, жесткий диск, сетевой интерфейс). Если в большинстве ОС драйверы устройств должны быть встроены в структуру ОС, в QNX Neutrino они могут запускаться и останавливаться как стандартные процессы. В результате добавление новых драйверов устройств не нарушает работу какой-либо части ОС, так как драйверы могут разрабатываться и подвергаться отладке как обычные приложения.

QNX Momentics IDE ‑ Интегрированная среда разработки приложений для операционной системы QNX Neutrino (рис.40). QNX Momentics IDE представляет собой профессиональный комплект разработчика, который поддерживает различные языки программирования (С, С++, Embedded С++ и Java), различные инструментальные ОС (Windows, Linux, или QNX Neutrino) и различные целевые процессоры (ARM, MIPS, PowerPC, SH-4 и x86) и позволяет существенно сократить время разработки встраиваемого проекта независимо от его масштаба и сложности.

Для разработки нестандартных драйверов применяются комплекты разработки драйверов (DDK), содержащие большую базу исходных текстов и готовых шаблонов. Отладка приложений вместе с драйверами выполняется с помощью одного и того же графического символьного отладчика [15].

Рис.40. Структура и функции QNX Momentics IDE

Q NX Momentics IDE позволяет оптимизировать производительность приложений с использованием профайлера приложений и анализатора ОЗУ, которые тесно интегрированы с остальными инструментами среды разработки. Системный профайлер и отладочная версия микроядра позволят визуально отслеживать проблемы синхронизации, взаимные блокировки и прочие часто возникающие ошибочные ситуации (рис. 41.).

Рис. 41. Профилирование кода

Для выполнения системного профилирования в состав QNX Momentics IDE входит пакет System Analysis Toolkit (SAT). В операционной системе происходят различные события, все они так или иначе проходят через миктоядро, поэтому основу SAT составляет модуль procnto-instr – Администратор процессов, с которым скомпоновано микроядро, оборудованное средствами диагностики. QNX утверждает, что производительность «истументированного» микроядра составляет не менее 98% производительности обычного микроядра. Средства, входящие в инструментальное расширение микроядра, записывают информацию о системных событиях в специальных буферах ядра (буферах трассировки) в виде записей (рис. 42).

Рис.42. Системное профилирование

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

1. С помощью утилиты qconn. В этом случае в качестве средства сбора данных используется утилита qconn, которая может на выбор сохранять данные в журнале трассировки на целевой системе или сразу отправлять их в виде потока средству визуализации – перспективе QNX System Profiler интегрированной среды разработки. Важным достоинством этого способа является возможность ограничивать перечень регистрируемых событий трассировки теми событиями, которые нас действительно интересуют – уж больно много информации собирает инструментальное ядро по умолчанию.

2. С помощью утилиты tracelogger. Утилита сохраняет данные в журнале трассировки. Для конвертирования данных в форму, удобную для чтения, следует или воспользоваться утилитой traceprinter, или написать свою программу обработчки журнала трассировки (в составе SAT есть специальная библиотека), или воспользоваться перспективой QNX System Profiler.

3. Управлять процессом трассировки из своего приложения, используя функцию TraceEvent(). Данные будут извлекаться из буферов трассировки в журнал с помощью утилиты tracelogger. Этот метод позволяет весьма тонко настраивать процесс трассировки.

По умолчанию и утилита tracelogger, и qconn заказывают у proc-instr 32 буфера. Каждый из буферов состоит из 1024 слов по 16 байт (т.е. каждый буфер имеет размер 16 кбайт). Событие ядра, для описания которого достаточно одного слота, называют fast. Те события, для описания которых недостаточно одного слота, называют wide.

Для управления трассировкой можно задавать фильтры:

• режим fast, wide. Fast указывает, что информация о wide-событиях должна обрезаться до размера fast. Это позволяет сэкономить слоты и увеличить скорость трассировки. Режим fast задан по умолчанию.

• Статический и динамический фильтры. Позволяют задавать правила записи событий в буферы, например, указывать, какие именно события нас интересуют. Статические фильтры используются утилитой qconn, динамический фильтр – это программа, использующая вызовы функции TraceEvent().

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

Midnight Commander — один из старейших файловых менеджеров в мире *NIX-систем [16]. Несмотря на то, что технологии давно ушли вперед, и жизнь без графического интерфейса существует только у системных администраторов, программа продолжает развиваться и по-прежнему остается востребованной среди пользователей Linux и QNX (рис.43).

Рис.43. Файловый менеджер Midnight Commander

Для работы Midnight Commander не требуется никаких графических библиотек, главное, чтобы всегда под рукой была консоль/терминал. Ранние версии файлового менеджера имели проблемы с русскими кодировками, но сегодня все ошибки исправлены, и можено просматривать и редактировать файлы, используя различние кодовые страницы. Текстовый редактор Midnight Commander имеет подсветку синтаксиса. В Midnight Commander можно создать обширное меню пользовательских команд, вызываемое клавишей F2.

Средства просмотра документов Midnight Commander имеют большое ограничение — отсутствие графического интерфейса. Формально, файловый менеджер может просматривать даже изображения. Программа правильно распознает тип данных, но вместо картинки отображает свойства изображения. Midnight Commander, не умея просматривать документы типа RTF, отлично справляется с форматрм DOC. А ведь DOC — это закрытый формат, имеющий структуру на порядок сложнее документа «со сложным форматированием» (Rich Text Format).

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

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