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

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

Эта проблема может быть решена применением «своих собственных» сообщений на основе общего механизма управляющих последовательностей, поддерживаемого в сообщениях типа _IO_MSG.

Сообщение типа _IO_MSG было предусмотрено для того, чтобы дать вам возможность вводить свои собственные типы сообщений, не конфликтуя при этом со «стандартными» типами сообщений администраторов ресурсов, поскольку для администраторов ресурсов сам тип сообщения _IO_MSG уже является «стандартным».

Первое, что вы должны сделать при использовании сообщений типа _IO_MSG — это определить ваши «специальные» сообщения. В этом примере мы определим два таких типа и последуем стандартной модели сообщений администратора ресурсов: один тип будет сообщением ввода, другой — вывода.

typedef struct {

int data_rate;

int more_stuff;

} my_input_xyz_t;

typedef struct {

int old_data_rate;

int new_data_rate;

int more_stuff;

} my_output_xyz_t;

typedef union {

my_input_xyz_t i;

my_output_xyz_t o;

} my_message_xyz_t;

Здесь мы определили новый тип — объединение (union) из сообщений ввода и вывода — и назвали этот тип my_message_xyz_t . Закономерность в имени идентификатора заключается в том, что это сообщение относится к службе « xyz » какова бы она ни была. Сообщение ввода имеет тип my_input_xyz_t , а сообщение вывода — my_output_xyz_t . Отметьте, что и «ввод», и «вывод» определяются с позиции администратора ресурса: «ввод» — это данные, поступающие в администратор ресурса, а «вывод» — это данные, поступающие из него (обратно клиенту).

Нам надо придумать какой-то вызов API для клиента — мы, конечно, можем принудить клиента «вручную» заполнять структуры my_input_xyz_t и my_output_xyz_t , но я не рекомендовал бы так делать по той причине, что API призван «отвязать» реализацию передаваемого сообщения от функциональности. Давайте предположим, что API клиента у нас такой:

int adjust_xyz(int * data_rate , int * оdata_rate ,

int * more_stuff );

Теперь мы имеем хорошо документированную функцию adjust_xyz() , которая выполняет нечто полезное для клиента. Заметьте, что для передачи данных мы использовали указатели на целые числа — это просто пример реализации. Вот текст функции adjust_xyz() :

int adjust_xyz(int *dr, int *odr, int *ms) {

my_message_xyz_t msg;

int sts;

msg.i.data_rate = *dr;

msg.i.more_stuff = *ms;

sts =

io_msg(global_fd, COMMAND_XYZ, &msg, sizeof(msg.i),

sizeof(msg.o));

if (sts == EOK) {

*odr = msg.o.old_data_rate;

*ms = msg.o.more_stuff;

}

return (sts);

}

Это пример применения функции io_msg() (ее мы скоро опишем — это не стандартный библиотечный вызов!). Функция io_msg() колдует над сборкой сообщения _IO_MSG. Чтобы уйти от проблемы функции devctl() с наличием только одного параметра размера, мы дали функции io_msg() два таких параметра: один — для ввода ( sizeof(msg.i) ), другой — для вывода ( sizeof(msg.о) ). Заметьте, что мы обновляем значения *odr и *ms только в том случае , когда функция io_msg() возвращает EOK. Это обычный прием, и здесь он полезен потому, что передаваемые аргументы не изменятся, если команда не завершится успешно. (Это предохраняет клиентскую программу от необходимости держать копию передаваемых данных на случай несрабатывания функции.)

Последнее, что я сделал в функции adjust_xyz() , — это зависимость от переменной global_fd , содержащей дескриптор файла администратора ресурса. Есть, опять же, множество способов обработки этого:

• Скрыть дескриптор файла внутри функции io_msg() (это было бы полезно, если бы вы пожелали избавиться от необходимости передавать дескриптор файла с каждым вызовом; это хорошо в случаях, когда вы собираетесь обмениваться сообщениями только с одним администратором ресурса, и не подходит в качестве универсального решения).

• Передавать от клиента дескриптор файла каждому вызову функции библиотеки API (полезно, если клиент хочет разговаривать с администратором ресурса еще и другими способами, например, стандартными POSIX-вызовами на основе файловых дескрипторов типа read() , или если клиент должен уметь общаться с несколькими администраторами ресурсов).

Вот текст функции io_msg() :

int io_msg(int fd, int cmd, void *msg, int isize,

int osize) {

io_msg_t io_message;

iov_t rx_iov[2];

iov_t tx_iov[2];

int sts;

// set up the transmit IOV

SETIOV(tx_iov + 0, &io_msg.o, sizeof(io_msg.o));

SETIOV(tx_iov + 1, msg, osize);

// set up the receive IOV

SETIOV(rx_iov + 0, &io_msg.i, sizeof(io_msg.i));

SETIOV(r.x_iov + 1, msg, isize);

// set up the _IO_MSG itself

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

io_message.type = _IO_MSG;

io_message.mgrid = cmd;

return (MsgSendv(fd, tx_iov, 2, rx_iov, 2));

}

Отметьте несколько вещей.

В функции io_msg() для «инкапсуляции» специального сообщения (передаваемого в параметре « msg ») в структуру io_message использован двухкомпонентный вектор ввода-вывода IOV.

Структура io_message была предварительно обнулена, и в ней был задан тип сообщения (_IO_MSG), а также инициализировано поле cmd (это будет использовано администратором ресурса для определения типа посылаемого сообщения).

В качестве кода завершения функции io_msg() использовался непосредственно код завершения MsgSendv() .

Единственная «забавная» вещь, которую мы тут сделали, касается поля mgrid . QSSL резервирует для данного поля диапазон значений со специальным поддиапазоном для «неофициальных» драйверов. Этот поддиапазон ограничен значениями от _IOMGR_PRIVATE_BASE до IOMGR_PRIVATE_MAX соответственно. Если вы разрабатываете глубоко встраиваемую систему и хотите быть уверены, что ваш администратор ресурса не получит никаких неподходящих сообщений, то смело можете использовать значения из этого специального диапазона. С другой стороны, если вы разрабатываете в большей степени «настольную» или «обычную» систему, вы можете захотеть точно проконтролировать, будут ли вашему администратору ресурса приходит несоответствующие сообщения или нет. В этом случае вам нужно будет обратиться в QSSL за значением mgrid , зарезервированным специально для вас — никто, кроме вас, не должен использовать это номер. Посмотрите файл , там представлены используемые в настоящее время диапазоны. В нашем вышепредставленном мы могли предположить, что COMMAND_XYZ базирована на _IOMGR_PRIVATE_BASE: