Введение в 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 — прим.ред.) и интерфейсом диспетчеризации (он позволяет комбинировать администраторы ресурсов и другие средства межзадачного взаимодействия) — все это описано в этой книге.
В августе 1999 года была официально выпущена QNX/Neutrino 2.00 — как раз к моменту выхода книги Роба! :-)
Я думаю, что это издание должно быть настольной книгой каждого, кто пишет программы для QNX/Neutrino.
Питер Ван Дер Вин (Peter van der Veen), С борта самолета где-то между Оттавой и Сан-Хосе, Сентябрь 1999 г.
Спустя несколько лет после того, как я приобщился к компьютерам, вышел в продажу первый IBM PC. Я был, наверное, одним из первых в Оттаве, кто купил этот ящик. В нем было 16Кб ОЗУ и не было видеокарты — неопытный продавец просто не знал, что без видеокарты машина будет абсолютно бесполезной. Впрочем, несмотря на бесполезность, на ящике было красиво написано «IBM» (а тогда такое можно было увидеть только на мэйнфреймах и им подобных), и это уже само по себе выглядело достаточно внушительно. Когда я наконец накопил денег на видеокарту, я смог даже запустить БЕЙСИК на телевизоре родителей. Для меня тогда все это было вершиной компьютерной технологии — особенно модем с акустической связью на 300 бод! А теперь представьте себе мою досаду, когда мне позвонил мой друг Пол Транли и сказал: «Эй, залогинься ко мне на компьютер?» Я подумал про себя: «А у него-то откуда VAX?» — поскольку из всех известных мне машин, на которые можно было «залогиниться», VAX была единственной, которая влезла бы в его дом. Я позвонил. Это был PC, работающий под загадочной операционной системой по имени «QUNIX», с номером версии меньше 1.00. Но там можно было сделать «login» — я был в шоке!
Что меня всегда поражало в операционных системах семейства QNX — это небольшой объем требуемой памяти, эффективность и абсолютная элегантность реализации. Я часто за едой развлекал (или утомлял, что более вероятно) приглашенных на ужин гостей своими баснями о программах, параллельно выполнявшихся на моей машине в подвале. Те, кто понимал в компьютерах, начинали прикидывать, какой у меня огромный диск, откуда у меня такой «неограниченный» объем ОЗУ, и т.п. После ужина я тащил их вниз, на мой этаж и показывал им свой простенький PC с 8Мб ОЗУ и винчестером на 70 Мб. На некоторых это действовало очень впечатляюще. Тем, на которых не действовало, я показывал, сколько ОЗУ и дискового пространства было еще доступно, при том что большую часть этого дискового пространства занимали мои собственные данные, которые я накопил за годы работы.
