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

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

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

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

2. Ответ администратора процессов: «Поговори сначала с fs-cache , а затем с fs-nfs ».

3. Сообщение fs-cache : «Мне хотелось бы открыть файл /nfs/home/rk/abc.txt на запись, пожалуйста».

4. Ответ от fs-cache : «Запросто, нет проблем».

Обратите внимание на то, что на 3 этапе мы открыли файл на запись, а не на чтение, как в первый раз. Поэтому не удивительно, что fs-cache на этот раз разрешает эту операцию (этап 4).

Еще более интересные события происходят, когда мы повторно пытаемся прочитать этот файл:

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

2. Ответ администратора процессов: «Поговори сначала с fs-cache , а затем с fs-nfs ».

3. Сообщение fs-cache : «Мне хотелось бы открыть файл /nfs/home/rk/abc.txt на чтение , пожалуйста».

4. Ответ от fs-cache : «Запросто, нет проблем».

Да-да, на этот раз fs-cache обработала запрос на чтение!

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

Дабы не путать понятия, сделаем небольшой экскурс в терминологию. Основное различие между объединенной файловой системой (UFS) и объединенной точкой монтирования (UMP) заключается в том, что UFS ориентирована на файлы, а UMP — на точки монтирования. В вышеупомянутой кеширующей файловой системе у нас была UFS, потому что оба администратора могли получить доступ к файлу вне зависимости от глубины его размещения файла в дереве каталогов. Давайте для примера рассмотрим другой администратор ресурса (назовем его « foobar »), отвечающий за путь « /nfs/other ». В UFS-системе процесс fs-cache был бы способен кэшировать файлы и оттуда тоже, присоединившись к « /nfs ». В случае с UMP, что принято в QNX/Neutrino по умолчанию, поскольку там все основано на соответствии самого длинного префикса, запросы смог бы обрабатывать только администратор foobar .

На этом с клиентом все. Перечислим ключевые моменты, которые следует запомнить:

• Клиент обычно налаживает связь с администратором ресурса с помощью вызова open() (или fopen() ).

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

• Все дальнейшие клиентские сообщения в этом сеансе основываются на дескрипторах файлов (или FILE* stream ) — например, read() , lseek() , fgets() , и т.п.

• Сеанс прекращается, когда клиент закрывает дескриптор файла или поток (или завершается по какой-либо причине).

Все вызовы, основанные на дескрипторах файлов, транслируются в сообщения.

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