Роб Кёртен - Введение в QNX/Neutrino 2. Руководство по программированию приложений реального времени в QNX Realtime Platform

Впервые взглянув на черновик этой книги, я подумал, что это будет трудное чтение, потому что сам много лет провел в разработке QNX/Neutrino. Но я ошибался! Я нашел книгу простой, понятной и занимательной — все дело в стиле Роба, сочетающем философию QNX («Почему все именно так, как оно есть») с полезными общими приемами, применимыми к любому проекту, связанному с задачами реального времени. Эта книга будет полезна как для читателей, никогда прежде не слышавших о Neutrino, так и для специалистов, которые активно используют ее в своих проектах.

Для тех, кто никогда не использовал QNX/Neutrino, книга представляет собой превосходное учебное пособие о том, как это делать. Поскольку Роб сам вышел из среды QNX2 и QNX4, его книга также будет очень полезна для специалистов, которые уже имели дело с QNX, поскольку ОС этого семейства имеют много общего.

Что до меня самого, то я впервые познакомился с QNX в середине 80-х, когда работал в страховой компании. Изначально там применялся IBM-овский мэйнфрейм, но компания хотела сократить время на расчеты квот для корпоративного страхования; для этого в компании решили применить сеть из 8-мегагерцовых 80286, работающих под управлением QNX2. Было решено распределить данные в прозрачной сети QNX, обеспечив тем самым доступ к файлам данных по всем заказчикам с любой QNX-машины. Клиент/серверная идеология QNX наделила систему такой грацией, что я влюбился в эту ОС с первого взгляда.

Я был приглашен работать в QSSL в начале 1991 года, когда была еще только-только выпущена QNX4. Она разрабатывалась в соответствии с техническими условиями только что утвержденной спецификации POSIX 1003.1, которые должны были сделать перенос общедоступных программ из UNIX проще, чем это было в QNX2, и подчинить ОС единому стандарту.

Спустя несколько лет мы стали задумываться о создании операционной системы следующего поколения. Группа из менее чем 15 разработчиков стала проводить локальные совещания, обсуждая всё то, что мы хотели бы сделать иначе, а также то, что могло нам понадобиться в будущем. Мы хотели обеспечить поддержку новых спецификаций POSIX и облегчить написание драйверов. Мы также не собирались ограничиваться процессорами серии x86 и «ремонтировать то, что работает».

Все фундаментальные идеи, которые Дэн Додж и Гордон Белл вложили в QNX изначально, действуют в QNX/Neutrino и по сей день — обмен сообщениями, микроядерная архитектура, предсказуемое время реакции, и т.д. Усложняла разработку QNX/Neutrino цель сделать ее более модульной, чем QNX4 (например, мы хотели создать полнофункциональное ядро, с которым можно было бы просто скомпоновать приложение, что позволило бы применять его в «более встраиваемых» приложениях по сравнению с QNX4). В 1994 году мы с Дэном Доджем начали работу над новой версией ядра и администратора процессов.

Те из вас, кто долго имел дело с QNX, знают, что от такой задачи как написание драйвера устройства для QNX2 волосы встают дыбом. Приходилось быть очень осторожным! В действительности, большинство разработчиков просто брали поставляемый с QNX2 исходный текст драйвера спулера и аккуратно прилаживали его под свои нужды. Лишь немногие пытались писать драйверы дисковых устройств, поскольку это требовало специализированных знаний из области ассемблера. Из-за этого практически никому не удавалось довести свои драйверы для QNX2 до конца. В QNX4 написание драйверов было значительно упрощено сведением всех стандартных операций ввода/вывода к четко определенному интерфейсу обмена сообщениями. Когда вы вызывали open() , сервер получал сообщение типа «открыть ресурс». Когда вы вызывали read() , сервер получал сообщение типа «читать данные». Главный выигрыш механизма обмена сообщениями в QNX4 состоял в том, что он развязывал серверы от клиентуры. Помнится, когда я впервые увидел бета-версию QNX 3.99 (пре-релиз QNX4), я подумал: «Вот это да! Как изящно все сделано!» Я был настолько очарован этим, что немедленно написал драйвер файловой системы для QNX2 с использованием этого нового механизма — все вдруг стало так просто!

Администратор процессов QNX/Neutrino был разработан с учетом трех основных независимых функций: управление пространством имен путей, создание и управление процессами и управление памятью. Он также поддерживал несколько дополнительных сервисов ( /dev/null , /dev/zero , образная файловая система, и т.д .), каждый из которых работал независимо, но все они разделяли общую схему обработки сообщений. Мы нашли эту схему настолько полезной, что решили выделить ее код в отдельную служебную библиотеку. Так появилась библиотека администратора ресурсов (или, как Роб любит ее называть, приводя меня в тихий ужас, «библиотека резмаггера». :-).

(«Resmgr» является стандартным, но труднопроизносимым сокращением от «resource manager». Роб, очевидно, решил упростить произношение и добавить гласных — так из «администратора ресурсов» (resource manager) получился «резервный индийский крокодил» (resmugger). Аналогично Роб, кстати, в свое время поступил и со своей фамилией, сделав из «крещеного» (Krten) «занавеску» (curtain) — прим. ред . :-)

Мы также обнаружили, что большинство администраторов ресурсов должны предоставлять своим устройствам или файловым системам семантику POSIX, поэтому поверх библиотеки администратора ресурсов был написан еще один дополнительный уровень — семейство функций iofunc*() . Это позволяет любому человеку писать администраторы ресурсов, автоматически наследующие функциональность POSIX — без каких-либо дополнительных усилий. Примерно в это время Роб писал курсы по QNX/Neutrino, и ему был нужен минимальный пример администратора ресурсов, /dev/null . Его основной слайд гласил: «Все, что от вас требуется — это написать обработчики вызовов read() и write() , и перед вами готовый /dev/null !» Я расценил это как вызов и убрал даже это требование — базированная на библиотеке администратора ресурсов реализация /dev/null теперь укладывается в примерно полдюжины вызовов. Поскольку эта библиотека поставляется с QNX/Neutrino, теперь каждый может писать POSIX-совместимые администраторы ресурсов с минимальными усилиями.

Однако, при том, что концепция администратора ресурсов была значительным шагом в эволюции QNX/Neutrino и обеспечивала мощный фундамент для операционной системы, новорожденная ОС требовала большего. Файловые системы, модули совместимости (например, TCP/IP) и устройства общего назначения, (последовательный интерфейс, консоли) разрабатывались параллельно. В результате огромной работы, в начале 1996 года вышла QNX/Neutrino 1.00. В течение последующих нескольких лет к работе над QNX/Neutrino стали привлекать все больше и больше специалистов отдела исследований и разработки (R&D) компании. Мы дополнили систему поддержкой SMP, многоплатформенностью (x86, PowerPC и MIPS) (на момент перевода также добавлена поддержка ARM, StrongARM и SuperH-4 — прим.ред .) и интерфейсом диспетчеризации (он позволяет комбинировать администраторы ресурсов и другие средства межзадачного взаимодействия) — все это описано в этой книге.