QNX - Золушка в семье UNIX

Принципы
Микроядро
Менеджер процессов
Менеджеры файловых систем
Менеджер устройств
Менеджер сети и FLEET-технология

Возможности масштабирования

Статья посвящена операционной системе QNX, разработанной канадской фирмой QNX Software Systems Ltd. (далее QSSL). Эта ОС практически неизвестна в нашей стране, но достаточно широко используется в Северной Америке и Европе. Данной публикацией мы пытаемся обратить внимание читателей на целый класс программного обеспечения, обычно выпадающий из поля зрения компьютерной прессы и, к сожалению, многих специалистов, чья профессиональная деятельность началась уже в пору тотального господства дуэта IBM/PC и MS-DOS. В этот класс входит программное обеспечение для автоматизации технологических процессов в промышленности и других областях деятельности, где одновременно требуются мультизадачность, надежность и способность работать в реальном масштабе времени (часто при наличии ограниченных аппаратных ресурсов). Существует устоявшийся термин - "Операционные системы реального времени", которым обычно определяют ОС, отвечающие указанным требованиям. ОС QNX является ярким представителем и одним из лидеров этого класса.

Немного истории

Те читатели, которые занимались компьютерными технологиями еще 6-10 лет назад, иногда с удивлением спрашивают друг друга, куда же все подевалось. Кто из них не помнит серию IBM-360/370 с OS/360, VM/SP или серию ВЕС PDP-11 с RSX-11М, или VAX? Те, кто в свое время успел прослушать классические курсы по операционным системам, вдруг с недоумением обнаружили, что все это, кажется, никому не нужно, поскольку новинка под названием MS-DOS совершила своеобразную революцию, начав историю развития универсальных ОС "от Адама", повторяя уже известные ошибки своих предшественниц. Компьютерные газеты и журналы начали неутомимо и настойчиво внушать всем, кто их читает, что "нет компьютера, кроме РС, и MS-DOS пророк его", хотя уже давно существовали Apple, MacIntosh, UNIX и многое другое (в том числе QNX).

Как же так получилось? Вероятно, сначала это было связано с обычными для нашей страны перекосами - как в свое время все дружно перешли на ЕС ЭВМ, так же в этот раз на IBM/PC. Потом, когда наступило "золотое время" компьютерного бизнеса, действовали экономические причины - IBM/PC были достаточно дешевы для массового потребления, а MS-DOS достаточно проста для самостоятельного изучения.

И в этом не было бы ничего плохого, если бы не один важный побочный эффект. Экспансия IBM/PC и MS-DOS привела к появлению целого поколения "специалистов-самородков", никогда не видевших ничего другого и "не ведающих, что творят". Каждый, кто смог нарисовать окошко в системе типа Clarion, стал называть себя программистом, потом эти программисты стали употреблять термин СУБД по отношению к штучкам типа dBase и даже Btrieve (как будто никогда не существовали IMS, IDMS или DB/2), наконец, появились Windows и NetWare, и эти люди почувствовали потребность в самореализации. К этому времени потенциальные клиенты созрели для автоматизации, и, конечно, вся страна неизбежно заболела Novell'ом и Clipper'ом. Мы не хотим принизить достоинства этих систем, но нелишне было бы вспомнить, для задач какого класса они предназначены. Проблема же заключается в том, что их стали пытаться использовать везде, где вообще можно вести речь об автоматизации. Вероятно, практически все банки и страховые компании прошли через этот этап, поскольку представляли собой первую очевидную мишень для автоматизаторов.

К счастью, уже около года как стали заметны признаки повсеместного выздоровления, хотя для многих это стоило больших денег и времени, потраченных впустую. Крупные промышленные предприятия, банки и биржи, телефонные и транспортные компании стали обращать свой взор на альтернативные решения, которые давно и успешно используются в развитых странах, где явление IBM/PC народу хотя и вызвало определенные сдвиги на рынке компьютерных технологий, но не привело к массовому беспамятству. Просто на этом рынке выделился сегмент, который стали называть SOHO (Small Office/Home Office), и IBM/PC стал доминирующей аппаратной платформой в этом сегменте, а MS-DOS и MS-Windows - программной платформой.

Тем временем в секторах банковских и промышленных приложений утвердились UNIX-системы на базе рабочих станций или мини-компьютеров и лишь в последнее время - на базе IBM/PC. До нас же это не доходило в силу того, что фирмы-производители не предпринимали усилий по продвижению подобных систем на наш рынок из-за его отсутствия до последнего времени. Кроме того, такие системы недешевы, а их установка и обслуживание требуют определенной квалификации, что препятствовало их импорту отечественными компаниями. Однако ситуация довольно быстро меняется, и уже многие крупные производители техники и программного обеспечения обратили взор на восток.

В связи с этим появились и соответствующие публикации в прессе, посвященные технологиям открытых систем, что постепенно приводит к заполнению образовавшегося вакуума информации. Но процесс этот идет все же довольно медленно, и информация касается в основном продукции тех фирм, которые вкладывают значительные средства в рекламу в нашей прессе. Это уже привело к тому, что распределение рынка между различными вариантами системы UNIX у нас отличается от среднемирового. Что же касается сектора приложений реального времени, который частично пересекается с секторами банковских и промышленных приложений, но имеет ряд специфических особенностей, то информации о соответствующих системах почти нет, за исключением единичных публикаций. Некоторую известность получили пока лишь VxWorks и Interactive Unix.

Операционная система QNX, о которой пойдет речь дальше, пока известна лишь сравнительно узкому кругу специалистов, а общедоступная информация о ней присутствует только в телеконференциях сети Relcom (comp.os.qnx). В обзорах, посвященных UNIX-системам, QNX практически никогда не упоминается на том основании, что это не совсем UNIX (а с архитектурной точки зрения, совсем не UNIX). Тем не менее, при ближайшем рассмотрении оказывается, что по многим параметрам ей нет равных в своем классе, а по наличию стандартного сервиса она постепенно все более приближается к универсальным ОС и, в принципе, может стать для них очень сильным конкурентом. Но обо всем по порядку...

Немного теории

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

Прежде всего проясним смысл выражения "реальный масштаб времени". Типичный пример представляет собой задачу управления вращающимся радиолокатором. Очевидно, что программа управления должна успевать обрабатывать поступающую от антенны информацию быстрее, чем она может вращаться, иначе данные будут теряться. Банальное решение с буферизацией, применяемое в обычных системах, принципиально неприемлемо (даже при наличии памяти неограниченного объема), поскольку информация, поступающая от локатора, привязана ко времени и устаревает уже через один оборот антенны. Представьте, что произойдет, если система управления начнет буферизовать данные о двух самолетах, которым угрожает столкновение. Кстати, задачи подобного типа тоже имеют специфическое наименование - критические приложения (mission-critical applications). Их общая черта - неприемлемо высокая цена сбоя или отказа оборудования.

На рассмотренном примере очень хорошо видна принципиальная особенность систем, работающих в реальном масштабе времени, - они должны обрабатывать поступающие данные быстрее, чем те могут поступать, причем от нескольких источников одновременно. Технически это означает, что программа (операционная система), претендующая на работу в таком режиме, должна обеспечивать не просто малое время реакции, а гарантированное время реакции. Разумеется, что это время должно быть достаточно малым, для того чтобы система была применима в реальных системах типа рассмотренной выше или, например, в системе управления ядерного реактора. Применительно к операционным системам, вышеуказанное принципиальное требование может быть выражено в виде нескольких архитектурных принципов и технических параметров, которые мы можем лишь перечислить и очень кратко рассмотреть ввиду ограниченности объема статьи.

Очевидно, что первым обязательным требованием к архитектуре ОС является многозадачность в истинном смысле этого слова. Варианты с многозадачностью типа MS-Windows или Novell NetWare неприемлемы, поскольку они допускают возможность блокировки или даже полного развала системы одним неправильно работающим процессом. Для предотвращения блокировок ОС должна использовать квантование времени (то есть принудительную, а не добровольную многозадачность), что является достаточно легкой задачей. Вторая проблема (надежность) может быть решена при полном использовании возможностей процессоров Intel 80386 и старше, что предполагает работу ОС в 32-разрядном режиме процессора. Для оперативного обслуживания прерываний ОС должна использовать алгоритм диспетчериза: ции, обеспечивающий вытесняющее планирование, основанное на приоритетах. Кроме того, необходима эффективная поддержка сетевых коммуникаций и взаимодействия между процессами, поскольку реальные технологические системы обычно управляются целым комплексом компьютеров и/или процессов. Весьма желательно, чтобы ОС поддерживала множественные нити управления, а также симметричную мультипроцессорность.

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

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

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

В упрощенном виде эта последовательность представлена на рисунке 1. Очевидно, что время Т^int зависит от содержания обработки прерывания, тогда как остальные времена зависят от архитектуры и реализации операционной системы. Как правило, для них выполняется соотношение Т^sl > T^il> T^iret. Кроме того, ОС определяет еще один характерный интервал, называемый временем переключения контекста. Этот интервал определяет, как часто каждый из активных процессов может получать управление при заданных параметрах квантования времени, и обычно он примерно на 20% больше, чем Т^sl. Таким образом, мы можем указать четыре временных параметра, определяющих "реактивные" характеристики ОС. Разумеется, эти характеристики зависят также от аппаратуры, но при проведении сравнительных испытаний выясняется, что при равных аппаратных условиях эти характеристики (и соответствующие параметры) могут очень сильно различаться у разных операционных систем, причем в тех случаях, когда различия очень велики, основная их причина заключается не в эффективности реализации, а в архитектурных различиях. Не случайно фирма QSSL. использует для рекламы ОС QNX девиз "Архитектура определяет разницу". Итак, мы подошли наконец к основному предмету данной статьи - обзору и анализу операционной системы реального времени QNX.

Архитектура QNX

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

Принципы

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

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

Микроядро

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

Размер микроядра в QNX составляет менее 10 КБайт. В его функции входит:

- передача сообщений: доставка сообщений от одного процесса к другому во всей операционной системе;

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

К выполнению функций "диспетчера" ядро приступает в следующих случаях:

- какой-либо процесс вышел из блокировочного состояния;

- истек квант времени для процесса, владеющего центральным процессором;

- работающий процесс прерван каким-либо событием.

Менеджер процессов

Отвечает за создание и удаление процессов, управление памятью, таймеры и эмуляцию сопроцессора, а также диагностику. Сертифицирован по стандарту POSIX 1003.1 и поддерживает многие расширения POSIX 1003.4. Существует в двух вариантах - 16-разрядная версия и 32-разрядная. Последняя способна исполнять как 16-, так и 32-разрядные приложения одновременно, для этого требуется лишь установка двух соответствующих разделяемых системных библиотек (фактически вы имеете две операционные системы в одной упаковке). Кроме того, эта версия использует все возможности процессоров Intel для аппаратной защиты памяти, в том числе механизм страниц. Своппинг на диск не поддерживается по принципиальным мотивам, поскольку он плохо совместим с требованиями к ОС реального времени (как мы увидим далее, своппинг в QNX не оченьто и нужен).

Менеджеры файловых систем

QNX позволяет работать с несколькими файловыми системами одновременно. В стандартный комплект поставки входят менеджеры файловых систем POSIX, DOS (FAT-12, FAT-16, все виды разделов) и ISO9660 (диски CD-ROM, включая расширения Rock Ridge). Файловая система POSIX семантически соответствует UNIX, при этом обеспечивается более высокая надежность (в том числе при отказе питания) и параллелизм в соответствии с POSIX 1003.1 (например, винчестер и флоппи-диски могут обслуживаться одновременно).

Менеджер устройств

Эффективно поддерживает байт-ориентированные устройства, позволяя осуществлять обмен со скоростью 115200 бод в мультизадачной среде на любом 386-м процессоре. Следует заметить, что использование буферизованных портов (UART) является совершенно необходимым при скоростях выше 2400 бод.

Менеджер сети и FLEET-технология

Сетевое взаимодействие является узким местом в большинстве операционных систем и обычно создает значительные проблемы для систем реального времени. Для того чтобы обойти это препятствие, разработчики QNX создали собственную специальную сетевую технологию FLEET и соответствующий протокол FTL (FLEET Transport Layer). Этот протокол не базируется ни на одном из распространенных сетевых протоколов типа IPX или NetBios и обладает рядом качеств, которые делают его уникальным.

Благодаря этой технологии, сеть компьютеров с QNX фактически можно представлять как один виртуальный суперкомпьютер. Все ресурсы любого из узлов сети автоматически доступны другим и для этого не,нужны фокусы типа RPC. Это значит, что любая программа может быть запущена на любом узле, при этом ее входные и выходные потоки могут быть направлены на любое устройство на любых других узлах.

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

Достигаются все эти удобства за счет того, что поддержка сети частично обеспечивается и микроядром (специальный код в его составе позволяет QNX объединять все микроядра в сети в одно ядро).

Разумеется, за такие возможности -приходится платить тем, что вы не можете получить драйвер для какой-либо сетевой платы от кого-либо еще, кроме фирмы QSSL, то есть использоваться может только то оборудование, которое уже поддерживается. Однако ассортимент такого оборудования достаточно широк и периодически пополняется новейшими устройствами.

Дополнительные менеджеры и утилиты

В комплект поставки входит стандартный набор утилит POSIX 1003.2, дополненный многими утилитами UNIX, не вошедшими в этот стандарт, специфическими утилитами QNX и весьма неплохим текстовым редактором vedit фирмы GreenView, напоминающим MultiEdit и позволяющим эмулировать большинство редакторов UNIX (vi, emacs и т.д.). Всего в стандартной поставке QNX насчитывается более 200 утилит.

Кроме того, отдельно могут поставляться менеджер интерфейса Socket (для поддержки сетей TCP/IP), эмулятор DOS, менеджер сбора данных (Data Acquisition Manager). В стадии тестирования находятся несколько новых менеджеров (например аудиоменеджер).

Менеджер TCP/IP поддерживает основные протоколы (IP, SLIP, РРР, ТСР, UDP, ICMP, ARP и др.) и большинство стандартных сервисов (rlogin, telnet, ftp, sendmail, NFS, RPC, DNS). Существует также его облегченная версия (без поддержки NFS). Этот менеджер появился сравнительно недавно, тем самым приблизив QNX к категории открытых систем. Его установка позволяет использовать узлы с QNX в гетерогенных сетях открытого типа.

С помощью эмулятора DOS можно запустить приложение DOS одновременно с процессами QNX (в том числе MS-Windows 3.1 в стандартном режиме и большинство Windows-приложений). Как правило, возможен запуск любого приложения DOS/Windows, не использующего нестандартных приемов работы. При этом приложение DOS может работать с файловой системой QNX и обмениваться данными с процессами QNX (через специальный интерфейс).

Менеджер сбора данных обеспечивает стандартизованный интерфейс для всевозможных устройств сбора и преобразования данных (ЦАП, АЦП и т.п.). Его основная область применения - АСУ и встроенные системы.

Графические подсистемы

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

Х Window System - система "верхнего края", обладающая самыми широкими возможностями и обеспечивающая переносимость ПО практически между любыми платформами. Однако, ее запросы не для слабонервных - минимум 8 МБ оперативной памяти (рекомендуется 16, а для разработки - 32) и от 80 до 250 МБ на диске. Реализация для QNX Х11 Release 5 выполнена фирмой MetroLink и обладает лучшими скоростными характеристиками среди существующих на сегодняшний день (тест Х11perf. дает результат 155000 Xstone's на 486DX2/66 с видеоплатой S3/928). Поставляется на CD-ROM в комплекте с библиотеками Athena и OSF/Motif 1.23, менеджерами окон twm и mwm, расширениями Xie (DEC Image Processing extention), Xv (Video extention), Xprio (MetroLink priority extention) и шрифтами РЕХ, Speedo, Adobe type 1, Utopia, bitmapped 75 dpi/100 dpi. Доступны также средства разработки приложений, (Х View, Х Designer и др. ).

Поддерживается около 100 наименований видеоплат (VGA, SVGA, 8514, S3, Mach8/32 и др.). В качестве документации поставляются книги из серии "The Definitive Guide to the Х Window System" издательства O'Reilly & Associates Inc. (13 томов объемом от 500 до 1000 страниц).

QNX Windows - Графическая система среднего звена, самая старая из трех рассматриваемых и единственная, способная работать в 16-разрядном режиме. Разработана фирмой Basis Computers Systems специально для QNX и сочетает удивительную компактность с довольно высокой эффективностью. Совместима с графическими интерфейсами OPEN LOOK и (в меньшей степени) OSF/Motif. Поставляется на дискетах в комплекте с Workplace-менеджером, File-менеджером (по стандарту OPEN LOOK), набором вспомогательных утилит, редактором интерфейсов, собственной документацией и книгой "OPEN LOOK Application Styles Gudelines". Для установки требуется всего около 6 МБайт на диске. Для запуска 32-х разрядной версии требуется около 1.5 МБайт свободной памяти и около 500 КБайт на каждое приложение. Поддерживаются видеоплаты VGA, SVGA(VESA), S3 и ATI Mach8/32, графические планшеты и некоторые другие специальные устройства ввода. Достоинствами системы являются также низкий сетевой трафик распределенных приложений и очень компактный API, позволяющий писать лаконичные программы.

Photon - самая компактная и самая молодая из рассматриваемых систем, которая находится еще в стадии бета-тестирования. Идеально подходит прежде всего для переносных и встроенных систем.

Разработана фирмой QSSL с учетом возможностей, предоставляемых QNX, и ограничений по памяти, присущих встроенным системам. Использует модульную технологию и способна работать в системах имеющих всего 256 КБайт свободной памяти. Новая технология, использованная в ней, позволяет создавать единое графическое пространство в рамках сети QNX (можно мышью перетащить окно с одного монитора на другой) и обеспечивает очень высокую производительность. Совместима с графическим интерфейсом OSF/Motif по внешнему виду. Поставляется с Motif-подобным менеджером окон, генератором приложений, средствами распознавания рукописного ввода и библиотекой совместимости с системой Х Window. Список поддерживаемых видеоплат включает все устройства, совместимые с VGA/SVGA, 8514, S3 и Mach8/32. Прикладной интерфейс построен по принципу Х Window (библиотека виджетов).

Средства разработки и дополнительное ПО

Средства разработки для ОС QNX поставляются одним из лидеров в этой области - фирмой Watcom International Corp. На сегодняшний день предлагаются QNX-версии компиляторов Watcom С (ANSI) и Watcom С++ (ANSI Level 3) - оба включают отладчик Watcom Wvideo и лицензию на средство удаленной отладки Ditto - и профилировщик Watcom Execution Profiler. Очередная версия компиляторов, которая уже появилась для среды DOS/ Windows, содержит также интегрированную среду разработки. Вероятно, она появится также и в QNX-версии, когда последняя будет выпущена. Кроме того, в связи с покупкой фирмы Watcom компанией PowerSoft, вполне вероятно появление QNX-версий, широко известных средств разработки этой фирмы (PowerBuilder и др.). Список дополнительного ПО, разработанного другими фирмами, составляет целую книгу. Упомянем только SQL-серверы Watcom SQL и Empress.

Возможности масштабирования

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

Эффективность и требуемые ресурсы

Эти качества являются одним из главных козырей QNX. Высокая эффективность обеспечивается в ней, с одной стороны, удачными архитектурными решениями, а с другой - эффективным использованием аппаратуры, что достигается с помощью специально разработанных драйверов. Требуемые ресурсы при этом ограничиваются 8 МБайт оперативной и 30-40 МБайт дисковой памяти (для среды разработки с графической подсистемой QNX Windows). Минимальная исполняющая система, загружаемая с сетевого сервера, требует лишь 512КБайт оперативной памяти. Короче говоря, вполне можно вести разработку на обычной 386SX/16 с 4МБайт памяти.

Для оценки эффективности приведем результаты тестов, выполненных на компьютерах со следующей базовой конфигурацией:

Как можно заметить из графиков, производительность сети Eternet составляет примерно 1 МБайт/сек (на плате NE-2000), что близко к теоретическому максимуму. Этот пример позволяет оценить степень эффективности протокола FTL и драйверов QNX. То же самое можно сказать о файловой системе и дисковых драйверах. Конечно, возникают вопросы о наличии в QNX драйверов для тех или иных устройств. Как уже отмечалось, выбор достаточно широк, и нет смысла перечислять здесь все. Отметим, что поддерживаются устройства практически всех известных типов, включая варианты для шин ISA, EISA, МСА, VLBus и PCI. Дисковые драйверы существуют для устройств типа IDE, ESDI, SCSI, SCSI-2, Fast SCSI-2, Fast Wide SCSI-2. Сетевые драйверы поставляются для плат типа Arcnet, Ethernet, Token Ring, FDDI, TCNS. CD-ROMы поддерживаются любые с интерфейсом SCSI и Mitsumi. Поддерживаются также платы типа SoundBlaster (пока только с интерфейсом SCSI).

Заключение

В настоящее время фирма QSSL проводит исследования и разработки, касающиеся следующего поколения ОС QNX под условным названием "проект Нейтрино". Этот проект предусматривает введение в систему средств для обеспечения работы на симметричных мультипроцессорных архитектурах, средств для поддержки множественных нитей управления и асинхронного ввода/вывода. Столь серьезные изменения потребовали усложнения архитектуры системы (кроме микроядра появилось еще и "наноядро"). Будет также реализован специальный механизм управления памятью, позволяющий определенным процессам использовать своппинг без ухудшения характеристик всей системы. После выхода подобной версии QNX сможет успешно конкурировать с универсальными ОС по всем параметрам. Кроме того, фирма QSSL в последнее время также заинтересовалась российским рынком. В прошлом году уже состоялась первая конференция пользователей QNX в России, что будет способствовать росту количества пользователей и росту популярности самой ОС. Одним словом, тем, кто сейчас выбирает программную UNIX-платформу, стоит повнимательнее присмотреться к этой "Золушке".