Хорошо, но ведь не каждое взаимодействие клиент/сервер сводится к блочной передаче данных (тот же сервер CLID — тому пример).
Трансляция сообщений в вызовы
devctl() или _IO_MSG
Итак, возник вопрос — как выполнять операции управления? Самый простой способ состоит в применении POSIX-вызова devctl(). Наш пример из библиотеки CLID примет вид:
/*
* CLID_AddSingleNPANXX(npa, nxx)
*/
int CLID_AddSingleNPANXX(int npa, int nxx) {
struct clid_addnpanxx_t msg;
checkAttach(); // Оставить или нет — дело вкуса
msg.npa = npa;
msg.nxx = nxx;
return
(devctl(clid_pid, DCMD_CLID_ADD_NPANXX,
&msg, sizeof(msg), NULL));
}
Как видите, операция относительно безболезненная. (Для тех, кто не любит devctl() за то, что приходится отправлять в обе стороны блоки данных одного и того же размера, см. ниже обсуждение сообщений _IO_MSG.). Опять же, если вы пишете программу, которая должна работать в обеих операционных системах, вам следует выделить функцию обмена сообщениями в отдельный библиотечный модуль и предоставить несколько вариантов реализации, в зависимости от применяемой операционной системы.
Реально мы убили двух зайцев:
1. отказались от глобальной переменной и стали собирать сообщения на основе стековой переменной — это делает нашу программу безопасной в многопоточной среде (thread- safe);
2. передали структуру данных нужного размера вместо структуры данных максимального размера, как мы это делали в предыдущем примере с QNX4.
Заметьте, что нам пришлось определить константу DCMD_CLID_ADD_NPANXX — в принципе, мы могли бы для этих же целей применить константу CLID_MsgAddSingleNPANXX (сделав соответствующее изменение в заголовочном файле), но я просто хотел подчеркнуть тот факт, что эти две константы не являются одинаковыми.
Второй убитый заяц заключался в том, что мы передали «структуру данных нужного размера». На самом деле, мы тут немножко приврали. Обратите внимание на то, что функция devctl() имеет только один параметр размера (четвертый, который мы установили в sizeof(msg)). Как на самом деле происходит пересылка данных? Второй параметр функции devctl() содержит команду для устройства (поэтому и «DCMD»). Двумя старшими битами команды кодируется направление, которое может быть одним из четырех:
1. «00» — передачи данных нет;
2. «01» — передача от драйвера клиенту;
3. «10» — передача от клиента драйверу;
4. «11» — двунаправленная передача.
Если вы не передаете данные (то есть достаточно просто команды) или передаете их в одном направлении, то применение функции 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 (это будет использовано администратором ресурса для определения типа посылаемого сообщения).
