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

fs-qnx4.so — файловой системы QNX4; fs-ext2.so — файловой системы Ext2; fs-dos.so — файловой системы FAT32; fs-cd.so — файловой системы ISO9660.

Администраторы файловых систем монтируют свои разделы в определенные точки файловой системы. Раздел QNX4, выбранный в процессе загрузки как первичный, монтируется в корень файловой системы — /. Остальные разделы по умолчанию монтируются в каталог /fs. Например, компакт-диск монтируется в точку /fs/cd, а файловая система FAT32 монтируется в точку /fs/hd0-dos.

Для того чтобы программа diskboot могла использовать раздел для поиска базового образа файловой системы QNX, необходимо наличие файла /.diskroot.

Операция по изменению информации на диске выполняется в форме транзакции, поэтому даже при катастрофических сбоях (например, при отключении питания) файловая система QNX4 остается цельной. В худшем случае некоторые блоки могут быть выделены, но не использованы, вернуть эти блоки можно, запустив утилиту chkfsys.

Дерево каталогов, которое пользователь привык видеть на экране, — это виртуальная файловая система, которая была создана и управляется администратором пакетной файловой системы fs-pkg.

6.3. Инсталляционные пакеты и их репозитарии

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

111

TGZ, т. е. все файлы компонуются в один утилитой tar, и этот файл сжимается утилитой gzip. Такой архив и есть QNX-пакет

— файл, имеющий расширение qpk.

Чтобы избавить пользователя от необходимости скачивать весь пакет для получения информации о производителе, версии, совместимости с другим программным обеспечением. Такого рода информация помещается в отдельный от пакета файл манифеста, имеющий расширение qpm. Одну или несколько пар файлов qpk и qpm можно с помощью тех же tar и gzip объединить в репозитарии qpr. В этом случае информация о содержимом репозитария помещается в отдельном файле-манифесте qrm. Репозитарий с его манифестом можно помещать на любом носителе — CD-ROM, веб-сайте и т. п. Для установки пакетов в операционную систему QNX используется уже знакомый вам инсталлятор QNX Software Installer — программа gnxinstall.

Рассмотренный нами тип репозитария — это репозитарий для хранения готовых к инсталляции пакетов программного обеспечения. В составе ОС QNX есть необходимые инструменты для построения собственных инсталляционных пакетов.

В самой ОС QNX есть два типа инсталляционных пакетов:

1)/pkgs/base для базовой системы QNX;

2)/pkgs/repository для дополнительного программного беспечения.

Эти пакеты, хранящиеся в соответствующих каталогах, содержат реальные объекты файловой системы на диске.

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

/pkgs/repository/производитель/ продукт/каталог_пакета Внутри каждого пакета обязательно есть XML-файл MANI-

FEST, который полностью описывает пакет. Остальные файлы и каталоги организованы таким образом, как они должны располагаться в файловой системе, причем корневым каталогом считается каталог пакета. Важная деталь: файлы и каталоги пакета, специфичные для какой-либо аппаратной архитектуры, располагаются в отдельном каталоге (ppcbe, x86, shle и т. д.).

112

Такой подход, с одной стороны, позволяет экономить дисковое пространство — платформо-независимый код не дублируется. С другой стороны, на одной ЭВМ можно без конфликтов хранить файловые системы для разных аппаратных платформ, что при сетевой прозрачности QNX обеспечивает широкие возможности для машин с ограниченными ресурсами.

Администратор пакетной файловой системы fs-pkg отображает содержимое файловой системы в привычном для пользователя виде, скрывая пакетную структуру данных. Некоторые каталоги существуют реально: /var, /tmp и другие создаются при первом старте ОС после инсталляции. Информация о конфигу-

рации пакетов хранится в файле /etc/system/package/packages.

Идеология пакетов предполагает их неизменность, т. е. пакеты должны быть доступны только для чтения. А что же делать, если требуется модифицировать или вообще заменить ка- кой-либо файл? Возможность таких изменений реализована с помощью каталога /var/pkg/spill. Именно туда помещаются измененные и добавленные файлы, а также записывается информация об «удалении».

Деинсталляция и деинициализация пакетов выполняются программой QNX Software Installer.

6.4. Символьные устройства ввода/вывода

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

•консольные устройства (или текстовые консоли);

•последовательные порты;

•параллельные порты;

•псевдотерминалы (ptys).

Для максимального использования кода управления символьными устройствами используется статическая библиотека io-char, которая управляет потоками данных между приложением

113

и драйвером устройства посредством очередей разделяемой памяти. Каждая очередь работает по принципу FIFO.

Режимы ввода при работе устройств:

•поточный, или «сырого ввода» (raw) — наиболее производительный режим, однако io-char не выполняет никаких редактирований принимаемых данных;

•редактируемый (edited) — режим, при котором io-char может выполнять операции редактирования над каждым символом строки. После окончания редактирования строки она становится доступной для обработки прикладным процессом (обычно после ввода символа возврата каретки CR). Такой режим часто именуют каноническим.

Консольные устройства

Системные консоли управляются процессами-драйверами devc-con или devc-tcon. Совокупность клавиатуры и видеокарты с монитором называют физической консолью.

Консольный драйвер devc-con позволяет запускать на физической консоли несколько терминальных сессий посредством виртуальных консолей. При этом devc-con организует несколько очередей ввода/вывода к io-char через несколько символьных устройств с именами /dev/con1, /dev/con2 и т. д. С точки зрения приложения создается эффект наличия нескольких консолей.

Консольный драйвер devc-tcon представляет собой «облегченную» (т. е. поддерживающую только одиночную консоль с «сырым» вводом) версию драйвера devc-con для систем с ограниченным объемом памяти.

Последовательные устройства

Последовательные каналы ввода/вывода управляются семейством процессов-драйверов devc-ser*. Каждый из драйверов может управлять более чем одним физическим устройством и обеспечивать поддержку нескольких символьных устройств.

Параллельные устройства

Параллельные принтерные порты (до четырех) управляются драйвером-процессом devc-par. Этот драйвер поддерживает только вывод, чтение из устройства /dev/раrn дает результат, аналогичный чтению из /dev/null.

114