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

Возвращает: Код завершения, при помощи вспомогательного макроса _RESMGR_STATUS .

int io_close_ocb(resmgr_context_t * ctp , void* reserved ,

RESMGR_OCB_T * ocb )

Классификация: Функция ввода/вывода (синтезируется библиотекой)

Обработчик по умолчанию: iofunc_close_default()

Вспомогательные функции: Нет

Клиентская функция: Нет (синтезируется библиотекой)

Сообщения: Нет (синтезируется библиотекой)

Структура данных:

// Синтезируется библиотекой

struct _io_close {

uint16_t type ;

uint16_t combine_len ;

};

typedef union {

struct _io_close i ;

} io_close_t;

Описание: Это функция, которая синтезируется базовым уровнем библиотеки, когда для некоего OCB получено последнее сообщение close() . Это то самое место, где вам следует «подчистить» все перед уничтожением OCB. Отметим, что идентификатор отправителя в ctp->rcvid есть нуль (0), потому что данная функция синтезируется библиотекой и не обязательно соответствует какому-либо конкретному сообщению.

Возвращает: Код завершения, при помощи вспомогательного макроса _RESMGR_STATUS .

int io_devctl(resmgr_context_t * ctp , io_devctl_t * msg ,

RESMGR_OCB_T * ocb )

Классификация: Функция ввода/вывода

Обработчик по умолчанию: iofunc_devctl_default()

Вспомогательные функции: iofunc_devctl()

Клиентская функция: devctl() , ioctl()

Сообщения: _IO_DEVCTL

Структура данных:

struct _io_devctl {

uint16_t type ;

uint16_t combine_len ;

int32_t dcmd ;

int32_t nbytes ;

int32_t zero ;

};

struct _io_devctl_reply {

uint32_t zero ;

int32_t ret_val ;

int32_t nbytes ;

int32_t zero2 ;

};

typedef union {

struct _io_devctl i ;

struct _io_devctl_reply o ;

} io_devctl_t;

Описание: Выполняет над устройством операцию ввода/вывода, переданную от клиентской функции devctl() в параметре dcmd . Клиент кодирует направление передачи данных двумя старшими разрядами dcmd , указывая этим, как функция devctl() должна передавать данные (поле «to» соответствует биту _POSIX_DEVDIR_TO, поле «from» — биту _POSIX_DEVDIR_FROM):

В случае, когда передачи данных нет, предполагается, что драйвер просто выполняет команду, заданную в dcmd . В случае передачи данных предполагается, что драйвер передает данные клиенту и/или обратно, используя вспомогательные функции resmgr_msgreadv() и resmgr_msgwritev() . Клиент указывает размер передачи в поле nbytes ; драйвер должен установить число передаваемых байт в поле nbytes исходящей структуры.

Отметим, что структуры данных, предназначенные для ввода и вывода, дополнены нулями, чтобы быть выровненными друг относительно друга. Это означает, что неявная область данных начинается в этих структурах с того же самого адреса.

Если вы используете вспомогательную функцию iofunc_devctl() , то имейте в виду, что если она не сможет сделать что-либо с сообщением devctl() , она возвратит вам константу _RESMGR_DEFAULT. Эта сделано для отделения корректных значений errno от возвращаемого признака «нераспознанная команда». Получив _RESMGR_DEFAULT, базовый уровень библиотеки ответит установкой errno в значение ENOSYS, которое будет транслировано клиентской библиотечной функцией devctl() в значение ENOTTY, «корректное» с точки зрения POSIX.

Проверка режима открытия и сопоставление его с выполняемой операцией лежит всецело на совести вашей функции — ни в клиентской devctl() , ни в библиотеке администратора ресурсов никаких проверок не выполняется. Например, можно открыть администратор ресурса в режиме «только для чтения», а затем выдать ему посредством devctl() команду «отформатировать жесткий диск» (которая, в общем, является весьма нехилой операцией записи). Так вот, с точки зрения администратора было бы весьма предусмотрительно до выполнения такой операции сначала проверить режим открытия ресурса.

Отметим, что диапазон доступных пользователю значений dcmd ограничен (значения от 0x0000 до 0x0FFF включительно зарезервированы QSSL). Другие значения можно смело использовать — см. заголовочные файлы с именами .