А. Робачевский - Операционная система UNIX (1114671), страница 71

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 71)

Приэтом ядро производит трансляцию имени и обнаруживает, что адресуемыйфайл принадлежит файловой системе specfs, через которую в дальнейшемпроизводятся все операции работы с файлом. В памяти размещается vnodeэтого файла и вызывается функция открытия файла для файловой системыspecfs — spec_openВ свою очередь spec_openнаходит требуемыйэлемент коммутатора c d e v s w [ ] и обнаруживает, что полененуле!вое. Тогда она вызывает процедуру подсистемы STREAMS stropenко!торая отвечает за размещение головного модуля и подключение драйвера.После выполнения необходимых операций поток приобретает вид, изо!браженный на рис.

5.22.Рис. 5.22. Структура потока после открытияwww.books-shop.comГлава 5.374Головной модуль представлен структурой stdata, которая выполняет рольинтерфейса между потоком и ядром системы при выполнении операцийчтения, записи и управления. Индексный дескрипторсодержит ука!затель на эту структуру. Поляструктур queue головного модулятакже указывают на stdata. Поляочередей queue указывают наструктурыадресующие общие для всех головных модулей функции,реализованные самой подсистемой STREAMS.Очереди чтения и записи драйвера связываются с соответствующими оче!редями головного модуля.

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

Обычно открытие потоков производится через драйвер клонов.После открытия потока процесс может произвести встраивание необходи!мых модулей. Для этого используется системный вызов ioctl(2). КомандаI_PUSH этой функции служит для встраивания модулей, а команда—для извлечения модулей из потока. Приведем типичный сценарий конст!руирования потока:fd =ioctl(fd,ioctl(fd,I_POP, (charioctl(fd, I_POP, (charВ этом примере процесс открыл поток /dev/stream, а затем последователь!но встроил модули modulel иЗаметим, что командасис!темного вызовавстраивает модуль непосредственно после голов!ного модуля.

После выполнения операций ввода/вывода, процесс извлекмодули и закрылПоскольку модули описываются такими же структурами данных, что идрайверы, схемы их встраивания похожи. Как и в случае драйверов, длязаполнения полей q_qinfo структур queue используются данные изструктуры streamtab модуля. Для хранения информации, необходимойдля инициализации модуля, во многих версиях UNIX используется табли!При закрытии потока все встроенные модули извлекаются автоматически.www.books-shop.comSTREAMS375ца fmodsw [ каждый элемент которой хранит имя модуля и указатель наструктуру streamtab. После установления всех связей вызывается функ!ция ххорепмодуля.Управление потокомУправление потоком осуществляется прикладным процессом с помощьюкоманд системного вызоваttinclude<stropts.h><sys/conf.h>int ioctl(int fildes, int command,Хотя часть команд обрабатывается исключительно головным модулем по!тока, другие предназначены промежуточным модулям или драйверу.

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

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

Обработка сообщениймодулем или драйвером выполняется в системном контексте и не имеетwww.books-shop.com376Глава 5.отношения к адресному пространству текущего процесса. Поэтому модульне имеет возможности копировать параметры команды и возвращать ре!зультаты обработки, используя адресное пространство задачи.Для преодоления этой проблемы в подсистеме STREAMS предлагаютсядва подхода.Первый из них основан на использовании специальной команды ioctl(2)При этом в качестве параметра передается указатель на структуруstrioctl:I_STR, (struct strioctlstruct strioctl {intintint ic_len;}где_ фактическая команда,_ число секунд, которое головной модуль будетожидать подтверждения запроса, послеонвернет процессу ошибку тайм!аута ETIME,_ размер блока параметров команды,ic_dp— указатель на блок параметров.Если головной модуль не может обработать команду, он формирует сооб!щениеи копирует в него командуи блок параметров(ic_len, ic_dp).

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

Обычно параметр arg является ука!зателем на блок параметров, размер и содержимое которого известнытолько модулю (или драйверу), отвечающему за обработку данной коман!ды. Поэтому головной модуль просто копирует этот указатель, не интер!претируя его и тем более не копируя в сообщение сам блок параметров.Сообщение передается вниз по потоку.www.books-shop.comSTREAMSКогда модуль получает сообщение, в ответ он отправляет сообщениеM_COPYIN, содержащее размер и расположениенеобходимых длявыполнения команды. Головной модуль пробуждает процесс, вызвавшийдля копирования параметров. Поскольку последующие операциивыполняются в контексте процесса, никаких проблем доступа к его адрес!ному пространству не возникает.

Головной модуль создает сообщениеM_IOCARGS, копирует в него параметры команды и направляет сообщениевниз по потоку. После этого процесс опять переходит в состояние сна.Когда модуль получает сообщениеон интерпретирует содер!жащиеся в нем параметры и выполняет команду. В некоторых случаях дляполучения всех параметров, необходимых для выполнения команды, мо!жет потребоваться дополнительный обмен сообщениями M_COPYIN иM_IOCARGS.

Такая ситуация может возникнуть, например, если один изпараметров являлся указателем на структуру данных. Для получения копииструктуры модулю потребуется дополнительная итерация.После получения всех необходимых данных и выполнения команды в слу!чае, если результат должен быть передан процессу, модуль формирует одноили несколько сообщений M_COPYOUT, помещая в них требуемые данные,и направляет их вверх по потоку. Головной модуль пробуждает процесс,передавая ему результаты выполнения команды. Когда все результаты пе!реданы процессу, модуль посылает подтверждениев результатекоторого головной модуль пробуждает процесс в последний раз, завершаятем самым выполнение вызова ioctl(2).МультиплексированиеПодсистема STREAMS обеспечивает возможность мультиплексированияпотоков с помощью мультиплексора, который может быть реализовантолько драйвером STREAMS.

Различают три типа мультиплексоров —верхний, нижний и гибридный. Верхний мультиплексор, называемый такжемультиплексором N:l, обеспечивает подключение нескольких каналоввверх по потоку к одному каналу вниз по потоку. Нижний мультиплексор,называемый также мультиплексором 1:М, обеспечивает подключение не!скольких каналов вниз по потоку к одному каналу вверх по потоку. Гиб!ридный мультиплексор, как следует из названия, позволяет мультиплекси!ровать несколько каналов вверх по потоку с несколькими каналами внизпо потоку.Расположение данных уже содержится в параметре arg, который передается обратно всообщенииCOPYIN.www.books-shop.com378Глава 5.Заметим, что подсистема STREAMS обеспечивает возможность мульти!плексирования, но за идентификацию различных каналов и маршрутиза!цию данных между ними отвечает сам мультиплексор.Мультиплексирование каналов вверх по потоку осуществляется в результа!те открытия одного и того же драйвера с различными младшими номера!ми.

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

Драйвер при этом будет обрабатывать две пары очередей,каждая из которых отвечает за отдельный поток. Когда данные поступаютот устройства, драйвер должен принять решение, в какую очередь чтенияих направить. Обычно такое решение делается на основании управляющейинформации, содержащейся в полученных данных. На рис. 5.23 представ!лен вид верхнего мультиплексора с двумя подключенными потоками.Рис. 5.23.

Верхний мультиплексорНижний мультиплексор представляет собой драйвер псевдоустройства.Вместо работы с физическим устройством он взаимодействует с несколь!кими каналами вниз по потоку. Для этого нижний мультиплексор обеспе!www.books-shop.comПодсистема STREAMS379чивает работу с еще одной парой очередей — нижними очередями чтенияи записи.

Характеристики

Список файлов книги