Введение в QNX/Neutrino 2. Руководство по программированию приложений реального времени в QNX Realtime Platform
Шрифт:
1. Направляет сообщение файловой системе
2. От файловой системы приходит ответ: «Запросто, никаких проблем!»
Теперь, после того как у функции open есть EOK («никаких проблем»), она возвращает дескриптор файла. Все дальнейшие операции клиент выполняет непосредственно с администратором сетевой файловой системы
Так когда же вступает в игру наша кеширующая файловая система
1. Сообщение администратору процессов: «С кем я должен переговорить насчет файла
2. Ответ администратора процессов: «Поговори сначала с
3. Сообщение
4. Ответ от
Обратите внимание на то, что на 3 этапе мы открыли файл на запись, а не на чтение, как в первый раз. Поэтому не удивительно, что
Еще более интересные события происходят, когда мы повторно пытаемся прочитать этот файл:
1. Сообщение администратору процессов: «С кем я должен переговорить насчет файла
2. Ответ администратора процессов: «Поговори сначала с
3. Сообщение
4. Ответ от
Да-да, на этот раз
Мы опустили несколько деталей, но для восприятия базовых идей они не так важны. Очевидно, кеширующая файловая система должна предусматривать некоторый способ отправки данных по сети на «реальный» носитель. Она также должна уметь перед отправкой данных клиенту проверять, не изменился ли файл (чтобы клиент не получил устаревшие данные). К тому же, кеширующая файловая система вполне могла бы сама обработать первый запрос на чтение, загрузив данные из сетевой файловой системы в свой кэш. И так далее.
Дабы не путать понятия, сделаем небольшой экскурс в терминологию. Основное различие между объединенной файловой системой (UFS) и объединенной точкой монтирования (UMP) заключается в том, что UFS ориентирована на файлы, а UMP — на точки монтирования. В вышеупомянутой кеширующей файловой системе у нас была UFS, потому что оба администратора могли получить доступ к файлу вне зависимости от глубины его размещения файла в дереве каталогов. Давайте для примера рассмотрим другой администратор ресурса (назовем его «
Резюме о клиенте
На этом с клиентом все. Перечислим ключевые моменты, которые следует запомнить:
• Клиент обычно налаживает связь с администратором ресурса с помощью вызова open (или fopen).
• После того как запрос клиента разрешился в конкретный администратор ресурса, мы его больше не меняем.
• Все дальнейшие клиентские сообщения в этом сеансе основываются на дескрипторах файлов (или
• Сеанс прекращается, когда клиент закрывает дескриптор файла или поток (или завершается по какой-либо причине).
Все вызовы, основанные на дескрипторах файлов, транслируются в сообщения.
Взгляд со стороны администратора ресурсов
Давайте теперь посмотрим на вещи с позиции администратора ресурса. Перво-наперво администратор ресурса должен сообщить администратору процессов, что он берет на себя ответственность за некоторую часть пространства имен путей (то есть зарегистрироваться). Затем он должен принимать сообщения от клиентуры и их обрабатывать. Очевидно, не так тут все просто.
Давайте кратко рассмотрим функции, реализуемые администраторами ресурсов, а затем уже углубимся в детали.
Регистрация префикса
Администратор ресурса должен сообщить администратору процессов, что одно или более имя пути теперь является его доменом ответственности — иными словами, что он готов обрабатывать клиентские запросы, относящиеся к этим именам путей.
Администратор последовательного порта способен обрабатывать (допустим, так) четыре последовательных порта. В этом случае он должен зарегистрировать у администратора процесса четыре различных имени пути:
Как правило, не следует регистрировать больше чем несколько дюжин отдельных префиксов, потому что поиск по дереву является линейным. Число 256 портов определенно больше. В таких случаях что мультипортовый администратор ресурсов должен сделать, так это зарегистрировать каталогоподобный префикс, например,