ЖУРНАЛ «СТА» №2/2007

94 СТА 2/2007 www.cta.ru О ДРАЙВЕРАХ И ОПЕРАЦИОННЫХ СИСТЕМАХ В отличие от множества печатных и электронных изданий, освещающих вопросы разработки драйверов для раз- личных операционных систем, матери- ал этой статьи обозначит общие черты систем, и особое внимание будет уделе- но принципам и организационной структуре драйверов, которая позволит успешно «собирать» их под ОС Windows 2000/XP/XP Embedded, Linux и QNX6. Множество устройств, пред- назначенных для расширения функций компьютера, как правило, оснащается драйверами под ОС Windows, домини- рующей на рынке домашних ПК. Нередко производитель оборудования уделяет внимание и операционной сис- теме Linux. Мир встраиваемых систем отличает интересная особенность, ка- кая бы ни была поставлена задача: сбор сигналов с датчиков, или управление ресурсами критических по времени объектов, или обеспечение функцио- нирования сложных систем цифровой обработки сигналов – в каждом случае мы можем выбрать отдельную операци- онную систему, которая будет успешно работать. Многообразие встраиваемых операционных систем (одних операци- онных систем реального времени на- считывается более ста) заставляет раз- работчика ПО соблюдать некоторые правила написания кода, чтобы при портировании драйвера под очередную ОС не приходилось проделывать всю работу с нуля и при этом сам код оста- вался «читабельным». Для встраивае- мых ОС и операционных систем реаль- ного времени (ОС РВ) традиционным подходом является модель кроссразра- ботки, когда инструментальная ЭВМ использует одну ОС (обычно это «клас- сическая» платформенная ОС типа Windows), а целевая – другую (рис. 1). Невероятно сложно, скорее всего не- возможно, написать драйвер без пони- мания внутреннего устройства опера- ционной системы. Поэтому, как мини- мум, необходимо иметь общие пред- ставления о следующих понятиях: ● процессы и нити, их различия в Windows и Unixсистемах, ● механизмы синхронизации, ● управление памятью — режим поль- зователя и режим ядра, понятия о выгружаемой памяти, ● отличие между пространством вво- давывода и памятью вводавывода, ● приоритеты и механизмы обработки прерываний, ● режим прямого доступа к памяти. С ТОИТ ЛИ ПИСАТЬ ПОРТИРУЕМЫЙ ДРАЙВЕР ? Термины «портируемый» и «перено- симый» можно рассматривать пораз- ному. Для когото код, написанный для разных версий компилятора, уже счи- тается переносимым. Под разработкой переносимого драйвера мы будем по- нимать создание такого проекта на языке Си, который бы мог компилиро- ваться не только разными компилято- рами (GCC, Microsoft C++), но и под разными архитектурами процессоров, например, ОС QNX работает на MIPS, PowerPC, SH4, ARM, StrongArm, Intel ® XScale™ Microarchitecture и x86. Кроме очевидного преимущества то- го, что кроссплатформенное про- граммное обеспечение может работать на разных типах компьютеров, есть ещё один немаловажный плюс — пор- тируемость хорошо влияет на сам код. Вопервых, ошибки, которые не рас- познает один компилятор, с лёгкостью могут быть обнаружены другим. Вовторых, общий исходный код для проектов под различными операцион- ными системами увеличивает робаст- ность, надёжность вашего кода и воз- можность повторного его использова- ния. И втретьих, тестирование прило- жения на разных платформах помогает в отладке — скрытая, трудновоспроиз- водимая ошибка может быть легко об- наружена на другой платформе. Казалось бы, между Windows, Linux и QNX нет ничего общего – это абсо- лютно разные системы с разной идео- логией и организацией. Однако, взгля- нув поглубже, можно отметить некото- рые «общие» черты, интересующие нас как разработчиков драйверов: ● ориентация на язык Си – компиля- торы существуют для всех платформ и архитектур; ● обращение к драйверу происходит так же, как и работа с обычными файлами, следовательно, примени- мы стандартные функции open(), read(), write() и другие; ● драйверы имеют схожую модель взаимодействия с системой (рис. 2). Заметим, что на схеме, представлен- ной на рис. 2, в частном случае биб- лиотека функций может отсутствовать. Стандартный приём создания перено- симого приложения — спрятать непор- тируемый код в отдельные модули. На рис. 3 показан один из возможных ва- риантов переносимого драйвера, пред- ставляющий собой двухуровневую структуру. На первом уровне находится общий портируемый код, который не должен зависеть от операционной сис- темы. На второй уровень будут добав- В ЗАПИСНУЮ КНИЖКУ ИНЖЕНЕРА Разработка переносимого драйвера устройства для встраиваемых систем Максим Овод LAN, WAN, RS 232… Инструментальная ЭВМ Целевая ЭВМ Рис. 1. Традиционная модель разработки ПО для встраиваемых систем