Операционная система UNIX - Робачевский Андрей Михайлович
При обработке сообщения промежуточным модулем или драйвером возникает проблема передачи данных. Как правило, команда ioctl(2) содержит ассоциированные с ней параметры, число и размер которых зависят от команды. При обработке команды ioctl(2) обычным драйвером последний имеет возможность копировать параметры из пространства задачи и подобным образом возвращать результаты, поскольку вся обработка команды происходит в контексте процесса.
Эта схема неприменима для подсистемы STREAMS. Обработка сообщений модулем или драйвером выполняется в системном контексте и не имеет отношения к адресному пространству текущего процесса. Поэтому модуль не имеет возможности копировать параметры команды и возвращать результаты обработки, используя адресное пространство задачи.
Для преодоления этой проблемы в подсистеме STREAMS предлагаются два подхода.
Первый из них основан на использовании специальной команды ioctl(2) I_STR. При этом в качестве параметра передается указатель на структуру strioctl:
ioctl(fd, I_STR, (struct strioctl*)arg);
struct strioctl {
int ic_cmd;
int ic_timout;
int ic_len;
char* ic_dp;
}
где ic_cmd — фактическая команда,
ic_timeout — число секунд, которое головной модуль будет ожидать подтверждения запроса, после он вернет процессу ошибку тайм-аута ETIME,
ic_len — размер блока параметров команды,
ic_dp — указатель на блок параметров.
Если головной модуль не может обработать команду, он формирует сообщение M_IOCTL и копирует в него команду (ic_cmd) и блок параметров (ic_len, ic_dp). После этого сообщение направляется вниз по потоку. Когда модуль получает сообщение, оно содержит все необходимые данные для обработки команды. Если команда предполагает передачу информации процессу, модуль записывает необходимые данные в то же сообщение, изменяет его тип на M_IOCACK и отправляет его вверх по потоку. В свою очередь головной модуль получает сообщение и производит передачу параметров процессу.
Другой подход получил название прозрачных команд ioctl(2) (transparent ioctl). Он позволяет использовать стандартные команды ioctl(2), решая при этом проблему копирования данных. Когда процесс выполняет вызов ioctl(2), головной модуль формирует сообщение M_IOCTL и копирует в него параметры вызова — command и arg. Обычно параметр arg является указателем на блок параметров, размер и содержимое которого известны только модулю (или драйверу), отвечающему за обработку данной команды. Поэтому головной модуль просто копирует этот указатель, не интерпретируя его и тем более не копируя в сообщение сам блок параметров. Сообщение передается вниз по потоку.
Когда модуль получает сообщение, в ответ он отправляет сообщение M_COPYIN, содержащее размер и расположение данных[65], необходимых для выполнения команды. Головной модуль пробуждает процесс, вызвавший ioctl(2), для копирования параметров. Поскольку последующие операции выполняются в контексте процесса, никаких проблем доступа к его адресному пространству не возникает. Головной модуль создает сообщение M_IOCARGS, копирует в него параметры команды и направляет сообщение вниз по потоку. После этого процесс опять переходит в состояние сна.
Когда модуль получает сообщение M_IOCARGS, он интерпретирует содержащиеся в нем параметры и выполняет команду. В некоторых случаях для получения всех параметров, необходимых для выполнения команды, может потребоваться дополнительный обмен сообщениями M_COPYIN и M_IOCARGS. Такая ситуация может возникнуть, например, если один из параметров являлся указателем на структуру данных. Для получения копии структуры модулю потребуется дополнительная итерация.
После получения всех необходимых данных и выполнения команды в случае, если результат должен быть передан процессу, модуль формирует одно или несколько сообщений M_COPYOUT, помещая в них требуемые данные, и направляет их вверх по потоку. Головной модуль пробуждает процесс, передавая ему результаты выполнения команды. Когда все результаты переданы процессу, модуль посылает подтверждение M_IOCACK, в результате которого головной модуль пробуждает процесс в последний раз, завершая тем самым выполнение вызова ioctl(2).
Мультиплексирование
Подсистема STREAMS обеспечивает возможность мультиплексирования потоков с помощью мультиплексора, который может быть реализован только драйвером STREAMS. Различают три типа мультиплексоров — верхний, нижний и гибридный. Верхний мультиплексор, называемый также мультиплексором N:1, обеспечивает подключение нескольких каналов вверх по потоку к одному каналу вниз по потоку. Нижний мультиплексор, называемый также мультиплексором 1:M, обеспечивает подключение нескольких каналов вниз по потоку к одному каналу вверх по потоку. Гибридный мультиплексор, как следует из названия, позволяет мультиплексировать несколько каналов вверх по потоку с несколькими каналами вниз по потоку.
Заметим, что подсистема STREAMS обеспечивает возможность мультиплексирования, но за идентификацию различных каналов и маршрутизацию данных между ними отвечает сам мультиплексор.
Мультиплексирование каналов вверх по потоку осуществляется в результате открытия одного и того же драйвера с различными младшими номерами. Верхний мультиплексор должен обеспечить возможность одновременной работы с устройством с использованием различных младших номеров. Если два процесса открывают поток, используя различные младшие номера, ядро создаст отдельный канал для каждого из них, каждый из них будет адресоваться отдельным vnode, и процедура <i>xx</i>open() драйвера будет вызвана дважды. Драйвер при этом будет обрабатывать две пары очередей, каждая из которых отвечает за отдельный поток. Когда данные поступают от устройства, драйвер должен принять решение, в какую очередь чтения их направить. Обычно такое решение делается на основании управляющей информации, содержащейся в полученных данных. На рис. 5.23 представлен вид верхнего мультиплексора с двумя подключенными потоками.
Рис. 5.23. Верхний мультиплексор
Нижний мультиплексор представляет собой драйвер псевдоустройства. Вместо работы с физическим устройством он взаимодействует с несколькими каналами вниз по потоку. Для этого нижний мультиплексор обеспечивает работу с еще одной парой очередей — нижними очередями чтения и записи. Структура streamtab нижнего мультиплексора адресует процедурный интерфейс работы с нижними очередями соответственно полями st_muxrinit и st_muxwinit.
