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

Нам надо придумать какой-то вызов 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, зарезервированным специально для вас — никто, кроме вас, не должен использовать это номер. Посмотрите файл <sys/iomgr.h>, там представлены используемые в настоящее время диапазоны. В нашем вышепредставленном мы могли предположить, что COMMAND_XYZ базирована на _IOMGR_PRIVATE_BASE:

#define COMMAND_XYZ (_IOMGR_PRIVATE_BASE + 0x0007)

или QSSL назначила нам специальный поддиапазон:

#define COMMAND_XYZ ( IOMGR_ACME_CORP + 0x0007)

«Клиент/сервер» с использованием администратора ввода/вывода

А что если клиент, которого вы переносите, использует администратор ввода/вывода? Как адаптировать его для QNX/ Neutrino? Ответ прост: мы уже это сделали. Установив интерфейс на основе файловых дескрипторов, мы уже используем администратор ресурса. В QNX/Neutrino вам почти никогда не придется использовать интерфейс «сырых» сообщений. Почему?

1. Вам пришлось бы самим беспокоиться о сообщении _IO_CONNECT, поступившим с клиентским вызовом open, или искать способ поиска администратор ресурса, альтернативный использованию open.

2. Вам пришлось бы искать способ сопоставить клиенту конкретный контекстный блок в администраторе ресурса. Это, конечно, не ракетная техника, но поработать придется.

3. Вам придется инкапсулировать все ваши сообщения вручную вместо использования стандартных POSIX-функций, которые бы сделали эту работу за вас.

4. Ваш администратор ресурса не будет работать с приложениями на основе stdin/stdout. В примере с аудиодрайвером вы не смогли бы просто так выполнить mp3_decode spud.mp3 >/dev/audio, потому что open, скорее всего, не сработала бы (а если бы и сработала, то не сработала бы write, и так далее).

Прокси

В QNX4 единственным способом передачи неблокирующего сообщения было создание прокси — это делалось с помощью функции qnx_proxy_attach. Эта функция возвращает идентификатор прокси (proxy ID), (он выбирается из того же самого пространства номеров, что и идентификаторы процессов), к которому вы затем можете применить функцию Trigger или возвратить его из функции обработки прерывания (см. ниже).