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

При возврате структур типа struct dirent код возврата, который передается клиенту, представляет собой число возвращенных байт.

Давайте для примера создадим администратора каталогового ресурса /dev/atoz. Этот администратор зарегистрирует «файлы» с именами от /dev/atoz/a до /dev/atoz/z, чтобы команда cat, примененная к любому из них, возвращала соответствующие их именам заглавные буквы. Чтобы понять, как это должно работать, вот пример командно-строковой сессии:

# cd /dev

# ls

atoz  null  ptyp2 socket ttyp0 ttyp3

enet0 ptyp0 ptyp3 text   ttyp1 zero

mem   ptyp1 shmem tty    ttyp2

# ls -ld atoz

dr-xr-xr-x 1 root 0 26 Sep 05 07:59 atoz

# cd atoz

# ls

a  e  i  m  q  u  y

b  f  j  n  r  v  z

c  g  k  o  s  w

d  h  l  p  t  x

# ls -l e

-r--r--r-x 1 root 0 1 Sep 05 07:59 e

# cat m

M# cat q

Q#

Приведенный пример показывает, что в каталоге /dev есть каталог atoz, и что к нему можно применить команду ls и выполнить в него cd. Данный каталог /dev/atoz имеет размер «26» — мы так задали в нашей программе. Сменив текущий каталог на atoz и выполнив еще одну ls, получаем его содержимое — файлы с именами от а до z. Выполнив ls для отдельного файла — в данном случае для файла e — мы видим, что файл доступен по чтению всем (часть «-r--r--r--») и имеет размер, равный 1 байту. Наконец, выполнение нескольких cat показывает, что файлы действительно имеют заявленное содержимое. (Отметим, что поскольку файлы содержат только один байт и не содержат символа новой строки, после вывода символа строка не переводится, и приглашение командного интерпретатора оказывается на той же самой строке, что и вывод cat.)

Теперь, когда мы знаем нужные характеристики, давайте посмотрим на код. Он разбит на следующие функции:

main() и декларации

Основная функция; здесь мы все инициализируем и запускаем наш администратор ресурса.

my_open()

Обработчик сообщения _IO_CONNECT.

my_read()

Обработчик сообщения _IO_READ.

my_read_dir() и my_read_file()

Выполняют фактическую работу функции my_read().

dirent_size() и dirent_fill()

Сервисные функции для работы со структурой struct dirent.

Заметьте, что при том, что разбит на короткие секции, перемежаемые текстовыми пояснениями, архив с полным исходным текстом в виде единого файла можно взять на веб-сайте компании PARSE Software Devices (http://www.parse.com/), он называется atoz.c.

Первый приведенный раздел программы представляет собой функцию main() и ряд деклараций. Для удобства объявлен макрос ALIGN(), который используется функциями dirent_size() и dirent_fill() для выравнивания.

Массив atoz_attrs содержит атрибутные записи, используемые в этом примере для «файлов». Мы объявляем массив из NUM_ENTS элементов, потому что у нас есть NUM_ENTS (то есть 26) файлов — от «а» до «z». Атрибутная запись, применяемая непосредственно для каталога (то есть для /dev/atoz, объявлена в теле функции main() и называется просто attr. Обратите внимание на различное содержимое у этих двух типов атрибутных записей:

Файловая атрибутная запись:

 Маркируется как обычный файл (константа S_IFREG) с режимом доступа 0444 (это означает, что доступ по чтению имеет каждый, но доступа по записи нет ни у кого). Размер равен «1» — файл содержит только один байт, а именно прописную букву, соответствующую своему имени. Индексные дескрипторы (inodes) этих файлов пронумерованы от «1» до «26» включительно (было бы удобнее взять числа от «0» до «25», но цифра «0» зарезервирована).

Каталоговая атрибутная запись:

Маркируется как файл типа «каталог» (константа S_IFDIR) с режимом доступа 0555 (это означает, что доступ по чтению и поиску имеет каждый, но доступа по записи нет ни у кого). Размер определен как «26» — это просто число, взятое по количеству элементов в каталоге. Индексный дескриптор выбран равным «27» — это число заведомо не используется больше ни в одной атрибутной записи.

Обратите внимание, что мы переопределили только поле open структуры connect_func и поле read структуры io_func. Для всех остальных полей сохранены POSIX-значения по умолчанию.

Наконец, обратите внимание, как мы создали имя /dev/atoz, используя resmgr_attach(). Наиболее важным здесь является то, что мы применили флаг _RESMGR_FLAG_DIR, который сообщает администратору процессов, что он может разрешать запросы на эту точку монтирования и ниже.

/*

 * atoz.с

 *

 * /dev/atoz с использованием библиотеки администратора ресурсов

*/

#include <stdio.h>

#include <stddef.h>

#include <stdlib.h>

#include <errno.h>

#include <dirent.h>

#include <limits.h>

#include <sys/iofunc.h>

#include <sys/dispatch.h>

#define ALIGN(x) (((x) +3) & ~3)

#define NUM_ENTS 26

static iofunc_attr_t atoz_attrs[NUM_ENTS];

int main (int argc, char **argv) {

 dispatch_t *dpp;

 resmgr_attr_t resmgr_attr;

 resmgr_context_t *ctp;

 resmgr_connect_funcs_t connect_func;

 resmgr_io_funcs_t io_func;

 iofunc_attr_t attr;

 int i;

 // Создать структуру диспетчеризации

 if ((dpp = dispatch_create()) == NULL) {

  perror("Ошибка dispatch_createn");

  exit(EXIT_FAILURE);

 }

 // Инициализировать структуры данных

 memset(&resmgr_attr, 0, sizeof(resmgr_attr));

 resmgr_attr.nparts_max = 1;

 resmgr_attr.msg_max_size = 2048;

 // Назначить обработчики по умолчанию

 iofunc_func_init(_RESMGR_CONNECT_NFUNCS, &connect_func,

  _RESMGR_IO_NFUNCS, &io_func);

 // Создать и инициализировать атрибутную запись для

 // каталога...

 iofunc_attr_init(&attr, S_IFDIR | 0555, 0, 0);

 attr.inode = NUM_ENTS + 1; // 1-26 зарезервированы для

                            // файлов от «a» до «z»

 attr.nbytes = NUM_ENTS; // 26 элементов в каталоге

 // ...и для имен от «a» до «z»

 for (i = 0; i < NUM_ENTS; i++) {

  iofunc_attr_init(&atoz_attrs[i], S_IFREG | 0444, 0, 0);

  atoz_attrs[i].inode = i + 1;

  atoz_attrs[i].nbytes = 1;

 }

 // Добавить наши функции; нам интересны только io_open

 // и io_read

 connect_func.open = my_open;

 io_func.read = my_read;

 // Зарегистрировать префикс

 if (resmgr_attach(dpp, &resmgr_attr, "/dev/atoz",

  _FTYPE_ANY, _RESMGR_FLAG_DIR, &connect_func,

  &io_func, &attr) == -1) {

  perror("Ошибка resmgr_attachn");

  exit(EXIT_FAILURE);

 }

 // Выделить контекст

 ctp = resmgr_context_alloc(dpp);

 // Ждать сообщений в вечном цикле

 while (1) {

  if ((ctp = resmgr_block(ctp)) == NULL) {

   perror("Ошибка resmgr_blockn");

   exit(EXIT_FAILURE);

  }

  resmgr_handler(ctp);

 }

}

При том, что функция my_open() очень невелика, в ней есть ряд критических мест. Обратите внимание, как мы принимаем решение о том, был ли ресурс открыт как «файл» или как «каталог», на основе только длины имени пути. Мы можем себе это позволить, потому что знаем, что других каталогов, кроме основного, в этом администраторе ресурсов нет. Если вы захотите расположить ниже вашей точки монтирования дополнительные каталоги, вам придется применить более сложный механизм анализа поля path структуры msg. В нашем простом примере, если в имени пути ничего нет, то мы знаем, что это каталог. Также обратите внимание на чрезвычайно упрощенную проверку корректности имени пути: мы просто проверяем, что у нас действительно только один символ, и что он лежит в диапазоне от «a» до «z» включительно. Опять же, в случае более сложного администратора ресурсов вам пришлось бы выполнять синтаксический анализа имени, следующего за зарегистрированной точкой монтирования.

Теперь о наиболее важной особенности. Обратите внимание, как мы использовали для выполнения всей нашей работы функции POSIX-уровня по умолчанию! Функция iofunc_open_default() обычно размещается в таблице функций установления соединения в той же самой ячейке, которую сейчас занимает наша функция my_open(). Это означает, что они принимают одинаковый набор аргументов!