Отклики, которые я получил на свои
предыдущие статьи, убедили меня в том, что
необходимо кардинально изменить стиль моих
публикаций. Мои статьи были слишком
поверхностны, вследствие чего те, кто до
этого ничего не знал о QNX, так ничего и не
поняли, а для тех, кто знал, они бесполезны.
Поэтому вместо сборника азбучных истин я
решил подготовить цикл статей, в каждой из
которых будет более-менее обстоятельно
рассматриваться один из вопросов,
связанных с ОСРВ QNX. Большинство материалов
одинаково верны (либо не верны :)) как для 4.х,
так и для 6.х.
Но перед этим несколько замечаний. Как мне
удалось выяснить, QNX когда-то называлась QUNIX.
По настоянию фирмы AT&T, владеющей торговой
маркой UNIX, название было изменено. Сначала я
решил, что буква Q, возможно, означает Quantum (прежнее
название QSS), но подтверждения своей версии
не нашел - везде написано, что Q = Quick (быстрый).
А ведь могло получиться очень забавно:
сначала ОС назвали по имени фирмы (QNX = Quantum
UniX), а затем фирму - по имени ОС (QSS = Qnx Software
Systems). Может, маркетологи QSS (которые недавно
полностью были замещены новыми кадрами)
решатся на очередное переименование?
Например, QSUX = QSs UniX :). Шучу, конечно, QNX - очень
громкий брэнд в мире встраиваемых систем, а
у QSS - очень грамотный отдел маркетинга,
управляет которым, между прочим, бывший
работник Микрософт (!). Уж что-что, а
маркетинг у М$ всегда был очень эффективный.
Фактически, это единственный
работоспособный отдел Корпорации. Впрочем,
это уже оффтопик.
Итак, архитектура системы определяется
архитектурой ядра. Это тем более верно для
встраиваемых систем, ведь в ПЗУ
промышленного робота, бортовой компьютер
ракеты-носителя ядерной боеголовки,
микропрограмму микроволновки (извините за
тавтологию), и все такое прочее, кроме ядра и
собственно программы управления данным
объектом ничего засовывать не будут.
Удаленное администрирование через TCP/IP и/или
ГУИ возможно, но используется редко. Один
человек совершенно справедливо назвал QNX
мечтой кришнаита: маленькая, никому не
мешает, тихо жужжит себе под нос, и делает
благое дело. Такое мнение он высказал, когда
совершенно случайно узнал, что один из
использующихся на его заводе станков с ЧПУ
работает под QNX2. В течение многих лет никто
не удосужился это выяснить просто потому,
что не было повода - перенастройки/апдейта/ребута/переустановки
не требовалось. Последние три действия
вообще не имеют смысла применительно к
встроенным системам. Во всяком случае, так
было раньше, до того, как на рынок
встроенных систем вышла всеми любимая Microsoft
с ее Windows XP Embedded Edition (и WinCE 3.0). Так что в
ближайшее время тебе понадобиться
перезагружать холодильник по десять раз на
дню (Произошло переполнение морозильника
по адресу ПолкаFFFF0001, если после разморозки
проблема возникнет снова, обратитесь в
ближайший супермаркет :)), а тостер при
попытке засунуть в него кусок батона будет
бить током, кричать про недопустимую
операцию и требовать исключительно
французских круассанов.
По поводу использования QNX в качестве
десктоп-системы (сервер, рабочая станция,
firewall/proxy, файловая мусорка, домашняя/игровая
машина) могу заявить сразу: возможно, но не
всегда, и почти никогда не оправдывает
материальных/интеллектуальных вложений.
Микроядро на десктопе - нонсенс. Обычно хост-система,
то есть тот комп, на котором идет разработка
встраиваемой системы, работает под обычной
OS (Windows, Solaris, Linux, HP-UX, etc). Встраиваемые ОСРВ
работают в специализированных
контроллерах, но некоторые из них допускают
использование на обычном компе (в смысле -
никуда не встраиваемом, но это не всегда
обычный IBM PC) в качестве среды разработки.
Использовать QNX RtP для разработки embedded-приложений
очень удобно, что не удивительно, так как
она разрабатывалась для этого, более того -
ТОЛЬКО для этого (ну, разве что еще для
саморекламы :)). Ставить ее на комп "просто
так" - глупость. Впрочем, лично меня это
соображение не остановило, чему я очень рад
:).
Опять меня занесло куда-то совсем далеко от
темы статьи... Итак, дубль 2. Основой
архитектуры QNX является микроядро, жесткое
реальное время и обмен сообщениями.
Используемое в QNX микроядро чрезвычайно
мало (около 8Кб в QNX4, от 20 до 32Кб в различных
реализациях QNX6), и полностью написано на
ассемблере, что обеспечивает высочайшую
скорость. Кроме того, в такой небольшой
программе легче находить ошибки, что делает
его чрезвычайно надежным. Конечно, 32
килобайта для программы на чистом
ассемблере не так уж и мало, но все же
учитывая соотношение между количеством
потраченных на разработку человеко-дней и
размером полученного бинарного кода, QNX
смело можно назвать одной из самых
проработанных ОС. Не удивительно, что ей
доверяют контроль над ядерными реакторами
и медицинским оборудованием. И то, и другое
напрямую связано с жизнью и здоровьем людей.
Ядро Кьюникса выполняет следующие задачи:
планирование процессов, обмен сообщениями
между процессами и... все! Нет, конечно, еще
есть сетевое взаимодействие низкого уровня
и первичная обработка прерываний, но
основных функций у ядра всего две. Это
фундамент операционной системы QNX.
1.Планировщик процессов.
Планировщик является частью ядра и
подключается каждый раз, когда процесс
меняет свое состояние в результате
появления сообщения или прерывания. В
отличие от процессов само ядро никогда не
планируется к выполнению. Управление
передается ядру только в результате
прямого вызова ядра из процесса, или по
аппаратному прерыванию.
Все функции, выполняемые операционной
системой QNX, за исключением функций ядра,
реализуются стандартными процессами. В
типичной конфигурации системы QNX имеются
следующие системные процессы:
администратор процессов (Proc), администратор
файловой системы (Fsys), администратор
устройств (Dev), сетевой администратор (Net).
Вот как примерно выглядят некоторые
команды в файле sysinit (инициализация системы):
# запуск менеджера устройств
Dev &
# драйвер консоли с восемью виртуальными
консолями
Dev.con -n 8 &
# открыть ввод-вывод на консоль
reopen //0/dev/con1
# последовательные порты (COM1/COM2)
Dev.ser &
# параллельный порт (LPT1)
Dev.par &
# диспетчер файловых систем
Fsys &
# драйвер флоповода
Fsys.floppy &
# администратор сети
Net &
# драйвер сетевой карты
Net.ether8003 &
# инициализация всех консолей и запуск login
на первой
tinit -T /dev/con* -t /dev/con1 &
Применение термина "системный процесс"
весьма условно - никакого отличия от
процессов пользователя нет. Ты можешь
называть их модулями, демонами, драйверами,
приложениями - суть не меняется. Абсолютно
любой процесс в QNX можно запустить или
остановить в любой момент. Никакого
сходства с Linux или BSD: тебе не нужно
компилировать ненужный в настоящий момент
кусок кода в виде модуля в надежде, что он
понадобиться в будущем. Во-первых, где
уверенность, что понадобиться? Во-вторых,
даже неподключенный модуль занимает память
и тормозит ядро. Да, я знаю, это глупо. Как
может программа занимать память, если она
не запущена? Почему работа компа
замедляется, хотя модуль не выполняется? Я
бы тебе объяснил, но статья посвящена
Кьюниксу, а не Линуксу :). Скажу только, что
никогда и ничего не компилирую в виде
модулей - лучше лишний раз пересобрать ядро.
Впрочем, я опять отвлекся, так что напомню: в
QNX таких проблем нет, можно развернуть
систему от минимальной инсталляции до
полнофункциональной, а потом обратно... без
перезагрузки (!), без перекомпиляции (!!), и
даже без непосредственного контакта с
конфигурируемым компьютером (!!!), то бишь
через сеть.
В начале статьи уже упоминалось, что
бОльшая часть изложенной здесь информации
справедлива и для QNX4, и для QNX6/Neutrino.
Фундаментальные принципы организации ядра
практически не изменились. Но все же есть по
крайней мере одно очень серьезное
нововведение в Neutrino. Еще раз подчеркиваю -
речь не о улучшениях ядра, их гораздо больше
одного, что заметно хотя бы по количеству
функций (в ядре QNX4 - 14 системных вызовов, в
Нейтрино - около пятидесяти), а об
изменениях базовых, "ядерных"
принципов.
(продолжение следует)
