Введение в QNX/Neutrino 2

 if ((msg->i.xtype & _IO_XTYPE_MASK) != _IO_XTYPE_NONE) (

  return (ENOSYS);

 }

 // Выяснить, сколько байт осталось...

 nleft = ocb->attr->nbytes — ocb->offset;

 // ...и сколько мы можем возвратить клиенту

 nbytes = min(nleft, msg->i.nbytes);

 if (nbytes) {

  // Создать ответную строку

  string = ocb->attr->inode - 1 + "A";

  // Возвратить ее клиенту

  MsgReply(ctp->rcvid, nbytes, &string + ocb->offset,

   nbytes);

  // Обновить флаги и смещение

  ocb->attr->flags |=

   IOFUNC_ATTR_ATIME | IOFUNC_ATTR_DIRTY_TIME;

  ocb->offset += nbytes;

 } else {

  // Возвращать нечего, индицировать конец файла

  MsgReply(ctp->rcvid, EOK, NULL, 0);

 }

 // Уже ответили сами

 return (_RESMGR_NOREPLY);

}

dirent_size()

Вспомогательная подпрограмма dirent_size() просто вычисляет число байт, необходимое для структуры struct dirent, с учетом ограничений по выравниванию. Опять же, для нашего простого администратора ресурсов здесь имеет место небольшое искусственное упрощение, потому что мы точно знаем, каков размер каждого элемента каталога — все имена файлов имеют длину ровно один байт. Однако, как бы там ни было, это все равно полезная служебная подпрограмма.

int dirent_size(char *fname) {

return (ALIGN(sizeof(struct dirent) - 4 + strlen(fname)));

}

dirent_fill()

И, наконец, вспомогательная подпрограмма dirent_fill() применяется для помещения передаваемых ей значений (а именно — полей inode, offset и fname) в также передаваемый ей элемент каталога. В порядке щедрости она также возвращает указатель на адрес (с учетом выравнивания), с которого должен начинаться следующий элемент каталога.

struct dirent* dirent_fill(struct dirent *dp, int inode,

 int offset, char *fname) {

 dp->d_ino = inode;

 dp->d_offset = offset;

 strcpy(dp->d_name, fname);

 dp->d_namelen = strlen(dp->d_name);

 dp->d_reclen =

 ALIGN(sizeof(struct dirent) - 4 + dp->d_namelen);

 return ((struct dirent*)((char*)dp + dp->d_reclen));

}

Резюме

Написание администратора ресурсов — наиболее сложная задача из описанных в этой книге.

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

Сообщения установления соединения

Относятся к операциям с именами путей, с их помощью можно устанавливать контекст для дальнейшей работы.

Сообщения ввода/вывода

Всегда следуют за сообщениями установления соединения и указывают, какую реальную работу нужно сделать для клиента (например, stat()).

Действия администратора ресурса управляются функциями пула потоков (мы обсуждали их в главе «Процессы и потоки») и функциями интерфейса диспетчеризации.

QSSL в библиотеке администратора ресурсов предоставляет ряд вспомогательных POSIX-функций, которые выполняют львиную долю работы по обслуживанию клиентских сообщений установления соединения и ввода/вывода, поступающих в администратор ресурсов.

Существует ряд структур данных, относящихся к клиентам и объявляемым администраторами ресурсов устройствам, которые необходимо принимать во внимание:

OCB (блок открытого контекста)

Выделяется при каждом «открытии» ресурса; содержат контекст для клиента (например, текущее смещение lseek()).

Атрибутная запись

Выделяется для каждого устройства; содержит информацию об устройстве (например, размер устройства, режимы доступа, и т.д.).

Запись точки монтирования

Распределяется на базисе по каждому администратору ресурса и содержит полную информацию о характеристиках администратора ресурса.

Клиент общается с администраторами ресурсов посредством обмена сообщениями, разрешив имя пути (с помощью функции open() и других вызовов) в соответствующий нужному администратору дескриптор узла, идентификатор процесса, идентификатор канала и обработчик (handle).

И наконец, вы наделяете администратор ресурса необходимой вам функциональностью, переопределяя некоторые из вызовов в таблицах функций установления соединения и функций ввода/вывода.

Приложение А Переход с QNX4 на QNX/Neutrino