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

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

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

#include

#include

#include

#include

#include

#include

#include

#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_create\n");

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_attach\n");

exit(EXIT_FAILURE);

}

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

ctp = resmgr_context_alloc(dpp);

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

while (1) {

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

perror("Ошибка resmgr_block\n");

exit(EXIT_FAILURE);

}

resmgr_handler(ctp);

}

}

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

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

Все, что мы должны сделать — это решить, какую атрибутную запись мы хотим связать с OCB, создаваемым функцией по умолчанию: либо каталоговую (в этом случае мы передаем attr ), либо одну из 26 имеющихся у нас файловых (тогда мы передаем соответствующий элемент atoz_attrs ). Это ключевой момент, поскольку обработчик, который вы помещаете в слот open в таблице функций установления соединения, действует как «швейцар» по отношению ко всем последующим запросам к вашему администратору ресурса.

static int my_open(resmgr_context_t *ctp, io_open_t *msg,