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

В приведенном ранее примере функции io_read() мы уже видели, как происходит возврат данных. Как было упомянуто в описании функции io_read() (в разделе «Алфавитный список функций установления соединения и ввода-вывода»), io_read() можно возвращать и элементы каталога тоже. Поскольку это может понадобиться далеко не всем, я решил рассмотреть этот вопрос здесь отдельно.

Прежде всего давайте посмотрим, почему и когда вашей io_read() могло бы понадобиться возвращать элементы каталога, а не «сырые» данные.

Если вы дискретно объявляете элементы в пространстве имени путей, и эти элементы не помечены флагом _RESMGR_FLAG_DIR, тогда вам не придется возвращать элементы каталога из функции io_read() . Если рассматривать это как «файловую систему», то ваш объект будет «файлом». Если же, с другой стороны, вы указываете _RESMGR_FLAG_DIR, то будет создан объект типа «каталог». Никто, кроме вас, не знает ничего о содержимом этого каталога, поэтому вы должны будете предоставить эти данные. Это и есть ответ на вопрос, почему функции io_read() может понадобиться возвращать элементы каталогов.

Вообще говоря, возврат элементов каталога — это почти то же самое, что и возврат «сырых» данных, за исключением того, что:

• вы должны возвратить целое число структур типа struct dirent ;

• эти структуры struct dirent должны быть заполнены.

Первый пункт означает, что вы не можете возвратить, например, семь с половиной структур struct dirent . Если восемь структур не вписываются в выделенное пространство, то вы должны будете возвратить только семь элементов.

Второй пункт достаточно очевиден. Он упомянут здесь только потому, что заполнение структуры struct dirent может быть несколько «хитрее», чем «сырой» подход к данным в случае с «обычной» io_read() .

Давайте взглянем на структуру struct dirent , поскольку это именно то, что возвращает функция io_read() в случае чтения каталога. Мы также вкратце рассмотрим клиентские вызовы, имеющие дело с элементами каталогов, поскольку у них со структурой struct dirent существует ряд интересных взаимоотношений.

Чтобы работать с каталогами, клиент использует функции closedir() , opendir() , readdir() , rewinddir() , seekdir() и telldir() .

Обратите внимание на сходство с «нормальными» функций для файлов (и совпадение применяемых типов сообщений):

Если мы на мгновение вообразим, что функции opendir() и closedir() будут обработаны для нас автоматически, мы сможем сконцентрироваться только на сообщениях типа _IO_READ и _IO_LSEEK и на соответствующих им функциях.

Сообщение _IO_LSEEK и соответствующая ему функция применяются для «поиска» (или «перемещения») в пределах файла. С каталогом происходит та же история. Вы можете переместиться к «первому» элементу каталога (как явно задав смещение функции seekdir() , так и вызвав функцию rewinddir() ) переместиться к любому произвольному элементу (используя функцию seekdir() ), или же узнать свою текущую позицию в списке элементов каталога (вызвав функцию telldir() ).

Однако, «хитрость» при работе с каталогами состоит в том, что смещения задаете вы сами, и управление ими тоже всецело лежит на вас . Это означает, что вы можете назначать смещения элементов в каталоге равными как «0», «2» и так далее, так и «0», «64», «128» и так далее. Единственно, что здесь необходимо предусмотреть — чтобы обработчики io_lseek() и io_read() одинаково трактовали эти смещения.

В приведенном ниже примере мы предположим, что используется простой подход с номерами «0», «1», «2», и т.д. (Вы могли бы использовать «0», «64», «128», и т.д., если бы эти числа соответствовали, например, неким смещениям на носителе. Выбор за вами!)

Ну вот, остается «просто» заполнить struct dirent «содержимым» нашего каталога. Структура struct dirent выглядит так (взято из ):

struct dirent {

ino_t d_ino ;

off_t d_offset ;

uint16_t d_reclen ;

uint16_t d_namelen ;

char d_name [1];

};

Коротко о ее полях:

При возврате структур типа struct dirent код возврата, который передается клиенту, представляет собой число возвращенных байт.

Давайте для примера создадим администратора каталогового ресурса /dev/atoz . Этот администратор зарегистрирует «файлы» с именами от /dev/atoz/a до /dev/atoz/z , чтобы команда cat, примененная к любому из них, возвращала соответствующие их именам заглавные буквы. Чтобы понять, как это должно работать, вот пример командно-строковой сессии:

# cd /dev

# ls

atoz null ptyp2 socket ttyp0 ttyp3

enet0 ptyp0 ptyp3 text ttyp1 zero

mem ptyp1 shmem tty ttyp2

# ls -ld atoz

dr-xr-xr-x 1 root 0 26 Sep 05 07:59 atoz

# cd atoz

# ls

a e i m q u y

b f j n r v z

c g k o s w

d h l p t x

# ls -l e

-r--r--r-x 1 root 0 1 Sep 05 07:59 e

# cat m

M# cat q

Q#

Приведенный пример показывает, что в каталоге /dev есть каталог atoz , и что к нему можно применить команду ls и выполнить в него cd . Данный каталог /dev/atoz имеет размер «26» — мы так задали в нашей программе. Сменив текущий каталог на atoz и выполнив еще одну ls , получаем его содержимое — файлы с именами от а до z . Выполнив ls для отдельного файла — в данном случае для файла e — мы видим, что файл доступен по чтению всем (часть « -r--r--r-- ») и имеет размер, равный 1 байту. Наконец, выполнение нескольких cat показывает, что файлы действительно имеют заявленное содержимое. (Отметим, что поскольку файлы содержат только один байт и не содержат символа новой строки, после вывода символа строка не переводится, и приглашение командного интерпретатора оказывается на той же самой строке, что и вывод cat .)