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

Кёртен Роб

Поиск администратора процессов

Теперь, когда мы знаем основные этапы поиска конкретного администратора ресурса, осталось раскрыть тайну поиска администратора процесса, с которого все начинается. На самом деле все очень просто. По определению, администратору процессов соответствует дескриптор узла 0 (то есть текущий узел), идентификатором процесса 1 и идентификатор канала 1. Так что администратор процессов всегда идентифицируется триплетом ND/PID/CHID, равным 0/1/1.

Обработка каталогов

Пример, рассмотренный выше, относился к администратору последовательного порта. Мы также высказывали предположение, что хотим

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

Предположим, у меня есть код, который делает следующее:

fp = fopen("/etc/passwd", "r");

Напомним, что функция fopen в конечном счете вызывает функцию open, так что реально мы имеем функцию open, запрашивающую имя пути

/etc/passwd

. Но такого имени на рисунке нет:

Пространство имен путей в QNX/Neutrino.

Однако, из рисунка видно, что модуль

fs-qnx4

зарегистрировал свою тройку ND/PID/CHID для имени пути «

/

». Хоть это и не показано на рисунке, файловая система

fs-qnx4

зарегистрировалась как «администратор каталога», сказав администратору процессов, что будет отвечать за «

/

» и все то, что расположено «ниже». «Администраторы устройств» (например, администратор последовательного порта) так не делают. Установив флаг каталога,

fs-qnx4

получает возможность обработать запрос для имени пути «

/etc/passwd

», потому что это имя начинается с «

/

», а значит, есть совпадение!

А что произошло бы, если бы мы попытались сделать так?

fd = open("/dev/ser1/9600.8.1.n", O_WRONLY);

Ну, поскольку у администратора последовательного порта не установлен флаг каталога, администратор процессов увидит эта и скажет: «Опаньки, извините,

/dev/ser1

— не каталог. В обработке отказано». Запрос прямо здесь и заканчивается — администратор процессов даже не возвращает функции open четверку ND/PID/CHID/handle.

Из параметров функции open в примере выше видно, что может показаться заманчивой идеей позволить некоторым «традиционным» устройствам открываться с дополнительными параметрами, указываемыми после «обычного» имени. Однако, эмпирическое правило здесь такое: если это пройдет на совещании по организации проекта, тогда вперед. Некоторые из моих студентов, услышав это от меня, заявляют: «Так я и есть сам себе комитет по проектным решениям!» На что я обычно отвечаю. «Пистолет у вас есть. Прострелите себе ногу. :-)»

Объединенные файловые системы

Взгляните повнимательнее на уже знакомый нам рисунок.

Пространство

имен путей в QNX/Neutrino.

Обратите внимание, что ответственными за префикс «

/

» объявили себя как файловая система

fs-qnx4

, так и администратор процессов. Это нормально, и беспокоиться тут не о чем. Мало того, иногда это оказывается очень даже неплохой идеей. Рассмотрим один такой случай.

Файловые системы с перекрытием

Предположим, что у вас очень медленное сетевое соединение, и вы смонтировали поверх него сетевую файловую систему. Вы замечаете, что некоторый файлы используются достаточно часто, и хотели бы, чтобы эти файлы неким волшебным способом «кешировались» на вашей машине, но увы и ах, проектировщики сетевой файловой системы это почему-то не предусмотрели. И тогда вы решаете самостоятельно написать кеширующую файловую систему (назовем ее, например,

fs-cache

) и поместить ее поверх сетевой файловой системы. Вот как это будет смотреться с позиции клиента:

Обе файловые системы,

fs-nfs

(сетевая файловая система) и ваша кэшированная файловая система (

fs-cache

) регистрируются под одним и тем же префиксом, «

/nfs

» уже упомянули выше, в QNX/Neutrino это нормально и абсолютно законно.

Предположим, что ваша система только что стартовала, и в вашей кэшированной файловой системе еще ничего нет. Клиентская программа пробует открыть какой-нибудь файл — скажем

/nfs/home/rk/abc.txt

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

Клиентский вызов open выполняет свои обычные действия:

1. Спрашивает администратор процессов: «К кому обратиться по поводу файла

/nfs/home/rk/abc.txt

?»

2. Получает ответ от администратора процессов: «Поговори сначала с

fs-cache

, а потом с

fs-nfs

».

Обратите внимание, что здесь администратор процессов возвращает две четверки ND/PID/CHID/handle — одну для файловой системы

fs-cach

e и одну для файловой системы

fs-nfs

. Это критично.

Далее функция open делает следующее:

1. Направляет сообщение файловой системе

fs-cache

. «Я бы хотел открыть файл

/nfs/home/rk/abc.txt

на чтение, пожалуйста.»

2. Получает ответ от файловой системы

fs-cache

: «Сожалею, но я никогда о таком не слышала.»

Здесь становится ясно, что с администратором файловой системы

fs-cache

клиентской функции open не повезло. Файл не существует! Однако, вызов open знает, что он получил список из двух четверок ND/PID/CHID/handle, и поэтому пробует второй вариант: