Введение в QNX/Neutrino 2

Из параметров функции 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-cache и одну для файловой системы 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.

Имя пути разрешается только один раз — во время вызова функции open(). Это означает, что как только мы успешно открыли нужный администратор ресурса, все дальнейшие вызовы, работающие с дескрипторами файлов, будут идти через него.

Так когда же вступает в игру наша кеширующая файловая система fs-cache? Ну, допустим, пользователь закончил считывание файла (файл теперь загружен в текстовый редактор). Когда файл понадобится сохранить, произойдет та же самая последовательность действий, но возникнет один любопытный поворот:

1. Сообщение администратору процессов: «С кем я должен переговорить насчет файла /nfs/home/rk/abc.txt?»