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

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() .