Подсистема ввода-вывода в UNIX. Драйверы

Архитектура подсистемы потокового ввода/вывода STREAMS впервые была описана в статье Ритчи "Потоковая система ввода/вывода" (Ritchie, D. М., "A Stream Input-Output System", AT&T Bell Laboratories Technical Journal, Vol. 63, No. 8, Oct. 1984) в 1984 году. Двумя годами позднее эта система была реализована в коммерческой версии UNIX SVR3.

Поводом для создания новой архитектуры ввода/вывода послужили несколько обстоятельств.

Традиционная система ввода/вывода, ориентированная на посимвольную передачу данных и рассмотренная ранее в этой главе, была изначально предназначена для работы с ограниченным числом низкоскоростных асинхронных терминальных устройств. Операционная система взаимодействует с такими устройствами (через точки входа в драйвер) на достаточно высоком уровне, возлагая основную обработку данных на драйвер. При этом только часть кода драйвера аппаратно зависима. Остальная обработка может являться однотипной для широкого спектра периферийного оборудования. По мере роста числа поддерживаемых операционной системой устройств использование стандартной архитектуры подсистемы ввода/вывода приводило к существенным накладным расходам, в частности, к неоправданному дублированию кода в ядре UNIX.

Другой побудительной причиной для разработки новой подсистемы ввода/вывода явилось отсутствие стандартного механизма буферизации данных для символьных устройств. По мере увеличения скоростей передачи, посимвольная обработка и передача стала неэффективной. Поэтому был разработан ряд подходов для обеспечения буферизации, например использование механизма, основанного на структуре clist, рассмотренного нами ранее. Однако такие схемы, по-прежнему обладая невысокой производительностью, по существу возлагают буферизацию данных на драйвер, что приводит к неэффективному распределению памяти.

Наконец, необходимость поддержки сетевых протоколов, большинство из которых имеют уровневую организацию, требует соответствующей архитектуры подсистемы ввода/вывода. Передача сетевых данных производится в виде пакетов или сообщений, при этом каждый уровень сетевого протокола производит определенную обработку и передает их другому уровню. Каждый уровень имеет стандартные интерфейсы взаимодействия с другими (верхним и нижним уровнями) и при этом может работать с различными протоколами верхнего и нижнего уровней. Например, протокол IP (уровень 3 модели OSI 5) может поддерживать работу нескольких протоколов верхнего уровня: TCP и UDP. На нижнем уровне протокол IP также взаимодействует с несколькими протоколами, обеспечивая передачу данных через различные сетевые интерфейсы (например, Ethernet, Token Ring

1.7.1 Модель OSI

Модель OS1 иерархии сетевых протоколов, предложенная Международной организацией по стандартам (ISO), включает определение функциональности для 7 уровней. Различные семейства протоколов, например TCP/IP или SNA, имеют то или иное отображение на эту модель. Эти вопросы рассмотрены в главе 6.

Процесс взаимодействует с потоком, используя стандартные системные вызовы ореп(2), close(2), read(2), write(2) и ioctl(2). Дополнительные функ-

Потоковый драйвер (драйвер STREAMS) имеет архитектуру, отличную от архитектуры драйверов символьных устройств, рассмотренных ранее.

Функции работы с потоками включают poll(2), putmsg(2) и getmsg(2). Передача данных по потоку осуществляется в виде сообщений, содержащих данные, тип сообщения и управляющую информацию. Для передачи данных каждый модуль, включая головной модуль и сам драйвер, имеет две очереди -- очередь чтения (read queue) и очередь записи (write queue). Каждый модуль обеспечивает необходимую обработку данных и передает их в очередь следующего модуля. При этом передача в очередь записи осуществляется вниз по потоку (downstream), а в очередь чтения -- вверх по потоку (upstream). Например, на рис. 5.13 из очереди записи модуля 2 сообщение может быть передано в очередь записи модуля 1, но не наоборот. В свою очередь сообщение из очереди чтения модуля 2 передается в очередь чтения головного модуля, который далее передает данные процессу в ответ на системный вызов read(2). Когда процесс выполняет системный вызов write(2), данные передаются головному модулю и далее вниз по потоку.

Процесс

ореп(), closeQ, readQ, writeQ, ioctlQ, pollQ, putmsg(), getmsgO

Интерфейс системных вызовов

Устройство

Рис. 5.13. Базовая архитектура потока

Сообщения также могут передаваться в парную очередь. Другими словами, из очереди записи модуля 1 сообщение может быть направлено в очередь чтения того же модуля, а затем, при необходимости, передано вверх по потоку. При этом модулю нет необходимости знать, какой части потока принадлежит следующая очередь -- головному или промежуточному модулю, или драйверу. Такой подход позволяет производить разработку модулей независимо друг от друга и использовать их затем в различных комбинациях и в различных потоках.

Подсистема STREAMS обеспечивает возможность такой комбинации благодаря механизму динамического встраивания (push) модуля в поток. Встраивание модуля возможно непосредственно после головного модуля. При этом будут установлены связи между соответствующими очередями встраиваемого модуля, головного модуля и модулей вниз по потоку. После этого встроенный модуль будет производить определенную обработку проходящих данных, тем самым изменяя изначальную функциональность потока. При необходимости модуль может быть извлечен (pop) из потока.

На рис. 5.14 показаны различные потоки, созданные из нескольких стандартных компонентов, для поддержки сетевых протоколов семейства TCP/IP. Причем модули IP, TCP и UDP могут поставляться одним производителем, а драйверы Ethernet или Token Ring -- соответствующими производителями сетевых адаптеров. В результате встраивания необходимых модулей первый поток будет обеспечивать передачу трафика TCP через адаптер Ethernet, в то время как второй -- передачу трафика UDP через адаптер Token Ring.

Рис. 5.14. Использование одних и тех же модулей для создания различных потоков

Подсистема STREAMS также обеспечивает возможность мультиплексирования потоков. Мультиплексирующий драйвер может быть подключен к нескольким модулям как вверх, так и вниз по потоку. Различают три типа мультиплексоров -- верхний, обеспечивающий мультиплексирование вверх по потоку, нижний, обеспечивающий мультиплексирование вниз по потоку, и гибридный, поддерживающий несколько потоков выше и ниже мультиплексора.

С помощью мультиплексирующих драйверов потоки, представленные на рис. 5.14, могут быть объединены в единый драйвер протоколов, поддерживающий несколько каналов передачи данных. Именно таким образом реализована поддержка сети во многих версиях операционной системы UNIX. Возможная организация компонентов STREAMS приведена на рис. 5.15.

Рис. 5.15. Конфигурация сетевого доступа с использованием подсистемы STREAMS

В этом случае модули TCP и UDP являются верхними мультиплексорами, а модуль IP реализован в виде гибридного мультиплексора7. Такая организация позволяет приложениям создавать потоки, используя различные комбинации сетевых протоколов и драйверов сетевых устройств. Задача

На самом деле мультиплексором может являться только драйвер STREAMS. Объединение драйверов в единый объект отлично от встраивания модулей и носит название связывания. Более подробно связывание и различия между модулями и драйверами STREAMS мы рассмотрим несколько позже в этой главе.

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

Модули

Модули являются основными компонентами потока. Каждый модуль состоит из пары очередей -- очереди чтения и записи, а также набора функций, осуществляющих обработку данных и их передачу вверх или вниз по потоку. Архитектура модуля представлена на рис. 5.16.

Рис. 5.16. Модуль STREAMS

Каждая очередь представлена структурой данных queue. Наиболее важными полями queue являются:

Помимо указанных полей, структура queue содержит параметры для обеспечения управления потоком данных -- верхнюю и нижнюю ватерлинии очереди.

Передача данных вверх или вниз по потоку осуществляется с помощью функций модуля, указатели на которые хранятся в структуре qinit. Модуль должен определить четыре процедуры для обработки каждой из очередей: xxput (), xxservice (), xxopen () и xxclose {), где хх, как и прежде, обозначает уникальный префикс драйвера. Эти функции адресуются указателями (*qi_putp) (), (*qi_srvp) (), (*qi_qopen) (),

(*qi_qclose) (). Этих четырех функций достаточно для взаимодействия с соседними модулями, обработки и передачи данных. Функция xxopen () вызывается каждый раз, когда процесс открывает поток или при встраивании модуля. Соответственно функция xxclose (} вызывается при закрытии потока или извлечении модуля. Функция xxput {) осуществляет обработку сообщений, проходящих через модуль. Если xxput () не может передать сообщение следующему модулю (например, в случае, если очередь следующего модуля переполнена), она помещает сообщение в собственную очередь. Периодически ядро вызывает процедуру xxservice () каждого модуля для передачи отложенных сообщений.

Модуль должен иметь функцию xxput {) для каждой очереди. Функция xxservice (} может не существовать, в этом случае xxput () не имеет возможности отложить передачу сообщения и должна передать его немедленно, даже если очередь следующего модуля переполнена. Таким образом модули, не имеющие процедур xxservice {), не обладают возможностью управления потоком данных. Эти аспекты мы подробнее рассмотрим в следующих разделах.

Оставшиеся поля структуры qinit:

moduie_inf о В этой структуре хранятся базовые значения таких парамет-

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

moduie_stat Эта структура непосредственно не используется подсистемой

STREAMS. Однако модуль имеет возможность осуществлять сбор разнообразной статистики своего участка потока с помощью полей этой структуры.

Сообщения

В подсистеме STREAMS все данные передаются в виде сообщений. С помощью сообщений передаются данные от приложений к драйверу и обратно. Сообщения используются для взаимодействия модулей между собой. Модули могут также генерировать сообщения для уведомления прикладного процесса или друг друга о возникновении ошибок или непредвиденных ситуаций. Таким образом, сообщения являются единственным способом передачи информации между различными компонентами потока и потому занимают ключевое место в подсистеме STREAMS.

Сообщение описывается двумя структурами данных: заголовком сообщения msgb (message block) и заголовком блока данных datab (data block). Обе эти структуры адресуют буфер данных, где находятся фактические данные сообщения.

Заголовок сообщения msgb имеет следующие поля:

b next, b_prev Используются для формирования связанного списка сообщений и соответственно адресуют следующее и предыдущее сообщение очереди

b_cont Указывает на продолжение сообщения и используется

для связывания различных частей одного сообщения
b_datap Указатель на заголовок блока данных

Ь rptr, b_wptr Указатели, определяющие расположение (начало и конец) данных в буфере данных Содержит ссылку на следующую структуру msgb

Заголовок блока данных datab используется для описания буфера и имеет следующие поля:

db_base Адрес начала буфера

db_lim Адрес ячейки памяти, следующей непосредственно

за буфером. Таким образом, размер буфера равен

db_lim -- db_base

db_type Тип сообщения

db ref Число заголовков сообщения, адресующих этот блок

Использование этих структур данных для формирования очереди сообщений и сообщений, состоящих из нескольких частей, показано на рис. 5.17.

Поле b_cont заголовка сообщения позволяет объединять несколько блоков данных в одно сообщение. Эта возможность особенно полезна при использовании подсистемы STREAMS для реализации сетевых протоколов. Сетевые протоколы имеют уровневую организацию. По мере передачи данных вниз по потоку, каждый последующий модуль (реализующий протокол определенного уровня) добавляет собственную управляющую информацию. Поскольку протоколы верхнего уровня не имеют представления об архитектуре нижних, невозможно заранее зарезервировать необходимую память под сообщение. Вместо того чтобы изменять размер буфера данных сообщения, модуль может добавлять управляющую информацию в виде отдельных частей, связывая их с помощью указателя b_cont. Этот процесс, получивший название инкапсуляции данных, графически представлен на рис. 5.18.

5.17. Сообщения STREAMS

Поле db__ref заголовка блока данных позволяет нескольким заголовкам сообщения совместно использовать один и тот же буфер. При этом происходит виртуальное копирование сообщения, каждая копия которого может обрабатываться отдельно. Как правило, такой буфер используется совместно только для чтения, хотя сама подсистема STREAMS не накладывает никаких ограничений, возлагая всю ответственность за обработку данных на модули потока.

Рис. 5.18. Инкапсуляция данных с использованием составных сообщений

В качестве примера виртуального копирования можно привести реализацию протокола TCP. Протокол TCP является надежным, т. е. данные считаются доставленными только после того, как от получателя поступит подтверждение. Это означает, что протокол должен хранить копии всех отправленных, но не подтвержденных сообщений. Вместо неэффективного физического копирования, производится виртуальное дублирование сообщения, одна копия которого затем передается вниз по потоку (модулю IP), а вторая сохраняется до получения подтверждения. После отправления сообщения драйвером сетевого адаптера, одна из копий будет уничтожена, что выразится в уменьшении поля db ref заголовка блока данных, но сам блок данных сохранится, поскольку значение счетчика по-прежнему будет превышать 0. И только после получения подтверждения db_ref станет равным 0, и соответствующий буфер будет освобожден.

1.7.2 Типы сообщений

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

М PR0TO

STREAMS определены следующие типы обычных сообще-

Содержит обычные данные. Например, системные вызовы read(2) и write(2) осуществляют передачу данных в виде сообщений этого типа.

_ Содержит управляющую информацию. Обычно сообщение этого типа

содержит также несколько блоков типа MDATA. С помощью системных вызовов putmsg(2) и getmsg(2) процесс имеет возможность отправлять и получать как управляющую часть сообщения (блок M_PROTO), так и данные (блоки m_data).

m_break Посылается драйверу устройства для генерации команды break.

m_passfp Используется в каналах STREAMS (STREAMS pipe) для передачи файлового указателя от одного конца канала к другому.

m_sig Генерируется модулями или драйверами и передается вверх по потоку головному модулю для отправления процессу сигнала.

m_delay Передается драйверу устройства и указывает задержку между последовательно передаваемыми символами. Как правило, используется при работе с медленными устройствами во избежание переполнения их буферов.

m__ctl Используется для взаимодействия модулей потока друг с другом.

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

M IOCTL Формируется головным модулем в ответ на управляющие команды, переданные процессом с помощью системного вызова ioctl(2):

I__LINK, I_UNLINK, I_PLINK, I PUNLINK И T_STR. Эти команды

используются для создания мультиплексированных потоков. Последняя команда используется для управления модулями потока.

MSETOPTS Используется для задания различных характеристик головного мо-

дуля.

m_rse Зарезервировано для внутреннего использования. Модули и драй-

веры должны передавать его без изменений.

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

М COPYIN

Передается вверх по потоку головному модулю и указывает ему скопировать данные от процесса для команды ioctl(2). Сообщение допустимо в интервале между получением сообщения M_IOCTL и сообщения м_юсаскили m__iocnak.

М COPYOUT

Передается вверх по потоку головному модулю и указывает ему передать данные, связанные с вызовом ioctl(2), процессу. Сообщение допустимо в интервале между получением сообщения M_IOCTL и сообщений miocack или m_iocnak.

М ERROR

M__FLUSH M_HANGUP

M__IOCACK

M_IOCNAK MPCPROTO

M^PCSIG

MPCRSE

M READ

Передается вверх по потоку головному модулю и указывает на возникновение ошибки вниз по потоку. Последующие операции с потоком будут заканчиваться ошибкой, за исключением системных вызовов close(2) и poll(2).

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

Передается вверх по потоку головному модулю и указывает, что драйвер не может передавать данные, обычно из-за обрыва линии (связи с удаленным объектом).

Подтверждение предыдущего сообщения mi ость. В ответ головной модуль возвратит необходимые данные процессу, сделавшему системный вызов ioctl(2).

Если выполнение команды ioctl(2) закончилось неудачей, это сообщение передается вверх по потоку головному модулю, в ответ на это последний возвратит процессу ошибку.

Высокоприоритетная версия сообщения m_proto.

Высокоприоритетная версия сообщения m_sig.

Зарезервировано для внутреннего использования в подсистеме.

Сообщение передается вниз по потоку, когда от процесса поступает запрос на чтение, но в головном модуле отсутствуют данные.

M_STOP M START

Предписывает немедленно прекратить передачу.

Предписывает продолжить передачу после останова, вызванного сообщением m_stop.

1.7.3 Передача данных

Как уже обсуждалось, передача данных в потоке происходит в виде сообщений. Процесс инициирует передачу данных с помощью системных вызовов write(2) и putmsg(2), которые непосредственно взаимодействуют с головным модулем. Головной модуль формирует сообщение, копируя в него прикладные данные, и передает его следующему модулю вниз по потоку. В конечном итоге сообщение принимается драйвером, который выполняет необходимые операции с конкретным устройством. В случае, когда драйвер получает данные от устройства, он также передает их в виде сообщений вверх по потоку. Процесс имеет возможность получить данные с помощью системных вызовов read(2) или getmsg(2). Если в головном модуле данные отсутствуют, процесс блокируется и переходит в состояние сна.

Сообщения передаются модулями с помощью системной функции putnext(9F):

iinclude <sys/stream.h> tinclude <sys/ddi.h>

int putnext(queue t *q, rablk^t *mp);

Эта функция адресует очередь следующего модуля параметром q и вызывает процедуру xxput () этой очереди, передавая ей сообщение тр. Не поощряется непосредственный вызов функции xxput () следующего модуля, поскольку это может вызвать определенные проблемы переносимости.

Передача данных внутри потока осуществляется асинхронно и не может блокировать процесс. Блокирование процесса возможно только при передаче данных между процессом и головным модулем. Таким образом, функции обработки данных потока -- xxput () и xxservice () не могут блокироваться. Если процедура xxput () не может передать данные следующему модулю, она помещает сообщение в собственную очередь, откуда оно может быть передано позже процедурой xxservice (). Если и процедура xxservice () не может осуществить передачу сообщения, например, из-за переполнения очереди следующего модуля, она не будет ожидать изменения ситуации, а вернет сообщение обратно в собственную очередь и завершит выполнение. Попытка передачи повторится, когда ядро через некоторое время опять запустит xxservice ().

Процедура xxservice () вызывается в системном контексте, а не в контексте процесса, который инициировал передачу данных. Таким образом, блокирование процедуры xxservice () может заблокировать (перевести в состояние сна) независимый процесс, что может привести к непредсказуемым результатам и потому недопустимо. Решение этой проблемы заключается в запрещении процедурам xxput () и xxservice () блокирования своего выполнения.

Блокирование недопустимо и для драйвера. Обычно прием данных драйвером осуществляется с использованием прерываний. Таким образом процедура xxput () вызывается в контексте прерывания и не может блокировать свое выполнение.

Когда процедура xxput () не может передать сообщение следующему модулю, она вызывает функцию putq(9F), имеющую следующий вид:

#include <sys/stream.h>

int putq(queue t *q, mblk_t *mp) ;

Функция putq(9F) помещает сообщение mp в очередь q, где сообщение ожидает последующей передачи, и заносит очередь в список очередей, нуждающихся в обработке. Для таких очередей ядро автоматически вызывает процедуру xxservice(). Планирование вызова процедур xxservicef) производится функцией ядра runqueues ()8. Функция runqueuesO вызывается ядром в двух случаях:

П Когда какой-либо процесс выполняет операцию ввода/вывода над потоком.

Непосредственно перед переходом какого-либо процесса из режима ядра в режим задачи.

Заметим, что планирование обслуживания очередей не связано с конкретным процессом и производится для всей подсистемы STREAMS в целом.

Функция runqueue () производит поиск всех потоков, нуждающихся в обработке очередей. При наличии таковых просматривается список очередей, ожидающих обработки, и для каждой из них вызывается соответствующая функция xxservice(). Каждая процедура xxservice(), в свою очередь, пытается передать все сообщения очереди следующему модулю. Если для каких-либо сообщений это не удается, они остаются в очереди, ожидая следующего вызова runqueue (), после чего процесс повторяется.

1.7.4 Управление передачей данных

Деление процесса передачи данных на два этапа, выполняемых, соответственно, функциями xxput () и xxservice (), позволяет реализовать механизм управления передачей данных.

Как уже упоминалось, обязательной для модуля является лишь функция xxput (). Рассмотрим ситуацию, когда модули потока не содержат процедур xxservice(). В этом случае, проиллюстрированном на рис. 5.19, каждый предыдущий модуль вызывает функцию xxput () следующего, передавая ему сообщение, с помощью функции ядра putnext(9F). Функция xxput {) немедленно вызываетputnext(9F) и т. д.:

xxput(queue_t *q, mblk_t *mp) {

putnext(q, mp);

Система планирования STREAMS использует собственные функции и НС ИМССТ ОТНОШС ния к планированию процессов в UNIX.

Когда данные достигают драйвера, он передает их непосредственно устройству. Если устройство занято, или драйвер не может немедленно обработать данные, сообщение уничтожается. В данном примере никакого управления потоком не происходит, и очереди сообщений не используются.

Хотя такой вариант может применяться для некоторых драйверов (как правило, для псевдоустройств, например, /dev/null), в общем случае устройство не может быть все время готово к обработке данных, а потеря данных из-за занятости устройства недопустима. Таким образом, в потоке данных9, и эта ситуация не может происходить блокирование передачи должна приводить к потере сообщений, во избежание которой необходим согласованный между модулями механизм управления потоком. Для этого сообщения обрабатываются и буферизуются в соответствующей очереди модуля, а их передача возлагается на функцию xxservice (), вызываемую ядром автоматически. Для каждой очереди опеределены две ватерлинии --

Блокирование передачи может происходить не только в драйвере (оконечном модуле) потока из-за занятости устройства. Возможна ситуация, когда отдельный модуль вынужден отложить обработку сообщений до наступления некоторого события.

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

Рассмотрим пример потока, модули 1 и 3 которого поддерживают управление потоком данных, а модуль 2 -- нет. Другими словами, модуль 2 не имеет процедуры xxservice (). Когда сообщение достигает модуля 3, вызывается его функция xxput (). После необходимой обработки сообщения, оно помещается в очередь модуля 3 с помощью функции putq(9F). Если при этом число сообщений в очереди превышает верхнюю ватерлинию, putq(9F) устанавливает специальный флаг, сигнализирующий о том, что очередь переполнена:

modlput(queue t *q, mblk t *mp)

{

/* Необходимая обработка сообщения*/

putq(q, mp);

}

Через некоторое время ядро автоматически запускает процедуру xxservice () модуля 3. Для каждого сообщения очереди xxput () вызывает функцию canput(9F), которая проверяет заполненность очереди следующего по потоку модуля. Функция сапрШ(9Г)имеет вид:

#include <sys/stream.h> int canput(queue t *q);

Заметим, что canput(9F)проверяет заполненность очереди следующего модуля, реализующего механизм управления передачей данных, т. е. производящего обработку очереди с помощью процедуры xxservice (). В противном случае, как уже говорилось, очередь модуля не принимает участия в передаче данных. В нашем примере, canput(9F) проверит заполненность очереди записи модуля 1. Функция возвращает истинное значение, если очередь может принять сообщение, и ложное -- в противном случае. В зависимости от результата проверки процедура xxservice () либо передаст сообщение следующему модулю (в нашем примере -- модулю 2, который после необходимой обработки сразу же передаст его модулю 1), либо вернет сообщение обратно в очередь, если следующая очередь переполнена.

Описанная схема показана на рис. 5.20. Ниже приведен скелет процедуры xxservice () модуля 3, иллюстрирующий описанный алгоритм передачи сообщений с использованием механизма управления передачей данных.

modlservice(queue t *q) {

mblk_t *mp;

while((mp = getq(q)) !=NULL) { if (canput(q->q next))

Рис. 5.20. Управление потоком данных

В этом примере функция getq(9F) используется для извлечения следующего сообщения из очереди, а функция putbq(9F) -- для помещения сообщения в начало очереди. Если модуль 1 блокирует передачу, т. е. canput(9F) вернет "ложно", процедура xxservice () завершает свою работу, и сообщения начинают буферизироваться в очереди модуля 3. При этом очередь временно исключается из списка очередей, ожидающих обработки, и процедура xxservice () для нее вызываться не будет. Данная ситуация продлится до тех пор, пока число сообщений очереди записи модуля 1 не станет меньше нижней ватерлинии.

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

В конечном итоге, модуль 1 обработает сообщения своей очереди, и их число станет меньше нижней ватерлинии. Как только очередь модуля 1 станет готовой к приему новых сообщений, планировщик STREAMS автоматически вызовет процедуры xxservice {) для модулей, ожидавших освобождения очереди модуля 1, в нашем примере -- для модуля 3.

Управление передачей данных в потоке требует согласованной работы всех модулей. Например, если процедура xxput () буферизирует сообщения для последующей обработки xxservice (), такой алгоритм должен выполняться для всех сообщений". В противном случае, это может привести к нарушению порядка сообщений, и как следствие, к потере данных.

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

Драйвер

Драйверы и модули очень похожи, они используют одинаковые структуры данных (streamtab, qinit, module^inо) и одинаковый интерфейс (ххореп (), xxput () , xxservice () и xxclose ()). Однако между драйверами и модулями существуют различия.

Во-первых, только драйверы могут непосредственно взаимодействовать с аппаратурой и отвечать за обработку аппаратных прерываний. Поэтому драйвер должен зарегистрировать в ядре соответствующий обработчик прерываний. Аппаратура обычно генерирует прерывания при получении данных. В ответ на это драйвер копирует данные от устройства, формирует сообщение и передает его вверх по потоку.

Во-вторых, к драйверу может быть подключено несколько потоков. Как уже обсуждалось, на мультиплексировании потоков построены многие

Это единственная ситуация, в которой возможно блокирование процесса. 1' Более точно -- для всех сообщений с данным приоритетом.

подсистемы ядра, например, поддержка сетевых протоколов. В качестве мультиплексора может выступать только драйвер. Несмотря на то что драйвер в этом случае не является оконечным модулем (см., например, рис. 5.15), размещение драйверов существенным образом отличается от встраивания модулей.

Наконец, процесс инициализации драйверов и модулей различен. Функция ххореп () драйвера вызывается при открытии потока, в то время как инициализация модуля происходит при встраивании.

1.7.5 Головной модуль

Обработку системных вызовов процессов осуществляет головной модуль. Головной модуль потока является единственным местом, где возможно блокирование обработки и, соответственно, процесса, в контексте которого осуществляется операция ввода/вывода. Головной модуль является внешним интерфейсом потока, и хотя его структура похожа на структуру обычного модуля, функции обработки здесь обеспечиваются самой подсистемой STREAMS. В отличие от точек входа в модуль или драйвер потока, реализующих специфическую для данного устройства обработку, функции головного модуля выполняют ряд общих для всех потоков задач, включающих:

Трансляцию данных, передаваемых процессом с помощью системных вызовов, в сообщения и передачу их вниз по потоку.

Сообщение об ошибках и отправление сигналов процессам, связанным с потоком.

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

Процесс передает данные потоку с помощью системных вызовов write(2) и putmsg(2). Системный вызов write(2), представляющий собой унифицированный интерфейс передачи данных любым устройствам, позволяет производить передачу простых данных в виде потока байтов, не сохраняя границы логических записей. Системный вызов putmsg(2), предназначенный специально для работы с потоками, позволяет процессу за один вызов передать управляющее сообщение и данные. Головной модуль преобразует эту информацию в единое сообщение с сохранением границ записи.

Системный вызов putmsg(2) имеет вид:

finclude <stropts.h>

int putmsg(int fildes, const struct strbuf *ctlptr, const struct strbuf *dataptr, int flags);

С помощью этого вызова головной модуль формирует сообщение, состоящее из управляющей части м PROTO и данных, передаваемых в блоках

М DATA. Содержимое сообщения передается с помощью указателей на структуру strbuf -- ctlptr для управляющего блока и dataptr для блоков данных.

Структура strbuf имеет следующий формат:

struct strbuf {

int maxlen;

int len;

void *buf; )

где maxlen не используется, len -- размер передаваемых данных, buf -- указатель на буфер.

С помощью аргумента flags процесс может передавать экстренные сообщения, установив флаг RS_HIPRI.

В обоих случаях головной модуль формирует сообщение и с помощью функции canput(9F) проверяет, способен ли следующий вниз по потоку модуль, обеспечивающий механизм управления передачей, принять его. Если canpul(9F) возвращает истинный ответ, сообщение передается вниз по потоку с помощью функции putnext(9F), а управление возвращается процессу. Если canput(9F) возвращает ложный ответ, выполнение процесса блокируется, и он переходит в состояние сна, пока не рассосется образовавшийся затор. Заметим, что возврат системного вызова еще не гарантирует, что данные получены устройством. Возврат из write(2) или putmsg(2) свидетельствует лишь о том, что данные были успешно скопированы в адресное пространство ядра, и в виде сообщения направлены вниз по потоку.

Процесс может получить данные из потока с помощью системных вызовов read(2) и getmsg(2). Стандартный вызов read(2) позволяет получать только обычные данные без сохранения границ сообщений12. В отличие от этого вызова getmsg(2) позволяет получать данные сообщений типов m_data и M_PROTO, при этом сохраняются границы сообщений. Например, если полученное сообщение состоит из блока м PROTO и нескольких блоков M_DATA, вызов getmsg(2) корректно разделит сообщение на две части: управляющую информацию и собственно данные.

Вызов getmsg(2) имеет вид:

ftinclude <stropts.h>

int getmsg(int fildes, struct strbuf *ctlptr,

struct strbuf *dataptr, int *flagsp);

- С помощью сообщения м SETOPTS можно дать указания головному модулю обрабатывать сообщения M_PROTO как обычные данные. В этом случае вызов read(2) будет возвращать содержимое как сообщений M_DATA, так и M_PROTO. Однако информация о типе сообщения (данных) и границы сообщений сохранены не будут.

С помощью вызова getmsg(2) прикладной процесс может получить сообщение, причем его управляющие и прикладные данные будут помещены в буферы, адресуемые ctlptr и dataptr соответственно. Так же как и в случае putmsg(2) эти указатели адресуют структуру strbuf, которая отличается только тем, что поле maxlen определяет максимальный размер буфера, a 1еп устанавливается равным фактическому числу полученных байтов. По умолчанию getmsg(2) получает первое полученное сообщение, однако с помощью флага RSHIPRI, установленного в переменной, адресуемой аргументом flagsp, процесс может потребовать получение только экстренных сообщений.

В обоих случаях, если данные находятся в головном модуле, ядро извлекает их из сообщения, копирует в адресное пространство процесса и возвращает управление последнему. Если же в головном модуле отсутствуют сообщения, ожидающие получения, выполнение процесса блокируется, и он переходит в состояние сна до прихода сообщения.

Когда головной модуль получает сообщение, ядро проверяет, ожидает ли его какой-либо процесс. Если такой процесс имеется, ядро пробуждает процесс, копирует данные в пространство задачи и производит возврат из системного вызова. Если ни один из процессов не ожидает получения сообщения, оно буферизуется в очереди чтения головного модуля.

1.7.6 Доступ к потоку

Как и для обычных драйверов устройств, рассмотренных ранее, прежде чем процесс сможет получить доступ к драйверу STREAMS, необходимо встроить драйвер в ядро системы и создать специальный файл устройства -- файловый интерфейс доступа. Независимо от того, как именно осуществляется встраивание (статически с перекомпиляцией ядра, или динамически), для этого используются три структуры данных, определенных для любого драйвера или модуля STREAMS: module_info, qinit и streamtab. Связь между ними представлена на рис. 5.21.

Структура streamtab используется ядром для доступа к точкам входа драйвера или модуля -- к процедурам его очередей ххореп (), xxclose (), xxput () и xxservice (). Для этого streamtab содержит два указателя на структуры qinit, соответственно, для обработки сообщений очереди чтения и записи. Два других указателя, также на структуры qinit, используются только для мультиплексоров для обработки команды I LINK, используемой при конфигурации мультиплексированного потока. Каждая структура qinit определяет процедуры, необходимые для обработки сообщений вверх и вниз по потоку (очередей чтения и записи). Функции ххореп () и xxclose {) являются общими для всего модуля и определены только для очереди чтения. Все очереди модуля имеют ассоциированную с ними процедуру xxput () , в то время как процедура xxservice () определяется только для очередей, реализующих управление передачей. Каждая структура qinit также имеет указатель на структуру module__info, которая обычно определяется для всего модуля и хранит базовые значения таких параметров, как максимальный и минимальный размеры передаваемых пакетов данных (mi_maxpsz, mi_minpsz), значения ватерлиний (mi_hiwat, mi lowat), а также идентификатор и имя драйвера (модуля) (miidnum, miidname).

Рис. 5.21. Конфигурационные данные драйвера (модуля) STREAMS

Доступ к драйверам STREAMS осуществляется с помощью коммутатора символьных устройств -- таблицы cdevsw[]. Каждая запись этой таблицы имеет поле d_str, которое равно NULL для обычных символьных устройств. Для драйверов STREAMS это поле хранит указатель на структуру streamtab драйвера. Таким образом, через коммутатор устройств ядро имеет доступ к структуре streamtab драйвера, а значит и к его точкам входа. Для обеспечения доступа к драйверу из прикладного процесса необходимо создать файловый интерфейс -- т. е. специальный файл символьного устройства, старший номер которого был бы равен номеру элемента cdevsw [ ], адресующего точки входа драйвера.

1.7.7 Создание потока

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

Рис. 5.22. Структура потока после открытия

Процесс открывает поток с помощью системного вызова ореп(2), передавая ему в качестве аргумента имя специального файла устройства. При этом ядро производит трансляцию имени и обнаруживает, что адресуемый файл принадлежит файловой системе specfs, через которую в дальнейшем производятся все операции работы с файлом. В памяти размещается vnode этого файла и вызывается функция открытия файла для файловой системы specfs -- specopen (). В свою очередь specopen () находит требуемый элемент коммутатора cdevsw[] и обнаруживает, что поле d_str ненулевое. Тогда она вызывает процедуру подсистемы STREAMS stropen (), которая отвечает за размещение головного модуля и подключение драйвера. После выполнения необходимых операций поток приобретает вид, изображенный на рис. 5.22.

Головной модуль представлен структурой stdata, которая выполняет роль интерфейса между потоком и ядром системы при выполнении операций чтения, записи и управления. Индексный дескриптор vnode содержит указатель на эту структуру. Поля q_ptr структур queue головного модуля также указывают на stdata. Поля q_qinfo очередей queue указывают на структуры qinit, адресующие общие для всех головных модулей функции, реализованные самой подсистемой STREAMS.

Очереди чтения и записи драйвера связываются с соответствующими очередями головного модуля. Информация, хранящаяся в структуре streamtab используется для заполнения полей q_qinfo соответствующих структур queue драйвера указателями на процедурные интерфейсы очередей чтения и записи.

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

После открытия потока процесс может произвести встраивание необходимых модулей. Для этого используется системный вызов ioctl(2). Команда IPUSH этой функции служит для встраивания модулей, а команда 1_Р0Р -- для извлечения модулей из потока. Приведем типичный сценарий конструирования потока:

fd = open("/dev/stream", О RDWR); ioctl(fd, I^PUSH, "modulel"); ioctl(fd, I PUSH, "module2");

ioctl(fd, I_POP, (char *}0); ioctl(fd, I_POP, (char *)0); close(fd));

В этом примере процесс открыл поток /dev/stream, а затем последовательно встроил модули modulel и modu!e2. Заметим, что команда l_PUSH системного вызова ioctl(2) встраивает модуль непосредственно после головного модуля. После выполнения операций ввода/вывода, процесс извлек 13 модули и закрыл

Поскольку модули описываются такими же структурами данных, что и драйверы, схемы их встраивания похожи. Как и в случае драйверов, для заполнения полей q_qinfo структур queue используются данные из структуры streamtab модуля. Для хранения информации, необходимой для инициализации модуля, во многих версиях UNIX используется таблица fmodsw [ ], каждый элемент которой хранит имя модуля и указатель на структуру streamtab. После установления всех связей вызывается функция ххореп () модуля.

1.7.8 Управление потоком

Управление потоком осуществляется прикладным процессом с помощью команд системного вызова ioctl(2):

ttinclude<sys/types.h> linclude <stropts.h> #include <sys/conf.h>

int ioctl(int fildes, int command, ... /* arg*/) ;

Хотя часть команд обрабатывается исключительно головным модулем потока, другие предназначены промежуточным модулям или драйверу. Для этого головной модуль преобразует команды ioctl(2) в сообщения и направляет их вниз по потоку. При этом возникают две потенциальные проблемы: синхронизация процесса с системным вызовом (поскольку передача сообщения и реакция модуля имеют асинхронный характер) и передача данных между процессом и модулем.

Синхронизацию осуществляет головной модуль. Когда процесс выполняет системный вызов ioctl(2), который может быть обработан самим головным модулем, последний выполняет все операции в контексте процесса, и никаких проблем синхронизации и копирования данных не возникает. Именно так происходит обработка ioctl(2) для обычных драйверов устройств. Если же головной модуль не может обработать команду, он блокирует выполнение процесса и формирует сообщение M_IOCTL, содержащее команду и ее параметры, и отправляет его вниз по потоку. Если какой-либо модуль вниз по потоку может выполнить указанную команду, в ответ он направляет подтверждение в виде сообщения М_ЮСАСК. Если ни один из модулей и сам драйвер не смогли обработать команду, драйвер направляет вверх по потоку сообщение M_IOCNAK. При получении одного из этих сообщений головной модуль пробуждает процесс и передает ему результаты выполнения команды.

При обработке сообщения промежуточным модулем или драйвером возникает проблема передачи данных. Как правило, команда 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 _ размер блока параметров команды,

icdp -- указатель на блок параметров.

Если головной модуль не может обработать команду, он формирует сообщение M_IOCTL и копирует в него команду (ic_cmd) и блок параметров (iclen, icdp). После этого сообщение направляется вниз по потоку. Когда модуль получает сообщение, оно содержит все необходимые данные для обработки команды. Если команда предполагает передачу информации процессу, модуль записывает необходимые данные в то же сообщение, изменяет его тип на М_ЮСАСК и отправляет его вверх по потоку. В свою очередь головной модуль получает сообщение и производит передачу параметров процессу.

Другой подход получил название прозрачных команд ioctl(2) (transparent ioctl). Он позволяет использовать стандартные команды ioctl(2), решая при этом проблему копирования данных. Когда процесс выполняет вызов ioctl(2), головной модуль формирует сообщение M_IOCTL и копирует в него параметры вызова -- command и arg. Обычно параметр arg является указателем на блок параметров, размер и содержимое которого известны только модулю (или драйверу), отвечающему за обработку данной команды. Поэтому головной модуль просто копирует этот указатель, не интерпретируя его и тем более не копируя в сообщение сам блок параметров. Сообщение передается вниз по потоку.

Когда модуль получает сообщение, в ответ он отправляет сообщение MCOPYIN, содержащее размер и расположение данных14, необходимых для выполнения команды. Головной модуль пробуждает процесс, вызвавший ioctl(2), для копирования параметров. Поскольку последующие операции выполняются в контексте процесса, никаких проблем доступа к его адресному пространству не возникает. Головной модуль создает сообщение M IOCARGS, копирует в него параметры команды и направляет сообщение вниз по потоку. После этого процесс опять переходит в состояние сна.

Когда модуль получает сообщение M_IOCARGS, он интерпретирует содержащиеся в нем параметры и выполняет команду. В некоторых случаях для получения всех параметров, необходимых для выполнения команды, может потребоваться дополнительный обмен сообщениями MCOPYIN и MIOCARGS. Такая ситуация может возникнуть, например, если один из параметров являлся указателем на структуру данных. Для получения копии структуры модулю потребуется дополнительная итерация.

После получения всех необходимых данных и выполнения команды в случае, если результат должен быть передан процессу, модуль формирует одно или несколько сообщений M_COPYOUT, помещая в них требуемые данные, и направляет их вверх по потоку. Головной модуль пробуждает процесс, передавая ему результаты выполнения команды. Когда все результаты переданы процессу, модуль посылает подтверждение м_ЮСАСК, в результате которого головной модуль пробуждает процесс в последний раз, завершая тем самым выполнение вызова ioctl(2).

Мультиплексирование

Подсистема STREAMS обеспечивает возможность мультиплексирования потоков с помощью мультиплексора, который может быть реализован только драйвером STREAMS. Различают три типа мультиплексоров -- верхний, нижний и гибридный. Верхний мультиплексор, называемый также мультиплексором N:l, обеспечивает подключение нескольких каналов вверх по потоку к одному каналу вниз по потоку. Нижний мультиплексор, называемый также мультиплексором 1:М, обеспечивает подключение нескольких каналов вниз по потоку к одному каналу вверх по потоку. Гибридный мультиплексор, как следует из названия, позволяет мультиплексировать несколько каналов вверх по потоку с несколькими каналами вниз по потоку.