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

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

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, и поэтому пробует второй вариант:

1. Направляет сообщение файловой системе fs-nfs : «Я бы хотел открыть файл /nfs/home/rk/abc.txt на чтение, пожалуйста.»

2. От файловой системы приходит ответ: «Запросто, никаких проблем!»

Теперь, после того как у функции open() есть EOK («никаких проблем»), она возвращает дескриптор файла. Все дальнейшие операции клиент выполняет непосредственно с администратором сетевой файловой системы fs-nfs .