Текст книги "Операционная система UNIX"

Автор книги: Андрей Робачевский

сообщить о нарушении

Текущая страница: 30 (всего у книги 39 страниц)

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

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

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

Структура streamtab используется ядром для доступа к точкам входа драйвера или модуля – к процедурам его очередей xxopen(), xxclose(), xxput() и xxservice(). Для этого streamtab содержит два указателя на структуры qinit, соответственно, для обработки сообщений очереди чтения и записи. Два других указателя, также на структуры qinit, используются только для мультиплексоров для обработки команды I_LINK, используемой при конфигурации мультиплексированного потока. Каждая структура qinit определяет процедуры, необходимые для обработки сообщений вверх и вниз по потоку (очередей чтения и записи). Функции xxopen() и xxclose() являются общими для всего модуля и определены только для очереди чтения. Все очереди модуля имеют ассоциированную с ними процедуру xxput(), в то время как процедура xxservice() определяется только для очередей, реализующих управление передачей. Каждая структура qinit также имеет указатель на структуру module_info, которая обычно определяется для всего модуля и хранит базовые значения таких параметров, как максимальный и минимальный размеры передаваемых пакетов данных (mi_maxpsz, mi_minpsz), значения ватерлиний (mi_hiwat, mi_lowait), а также идентификатор и имя драйвера (модуля) (mi_idnum, mi_idname).

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

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

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

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

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

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

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

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

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

fd = open(«/dev/stream», O_RDWR);

ioctl(fd, I_PUSH, «module1»);

ioctl(fd, I_PUSH, «module2»);

...

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

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

close(fd);

В этом примере процесс открыл поток /dev/stream, а затем последовательно встроил модули module1 и module2. Заметим, что команда I_PUSH системного вызова ioctl(2) встраивает модуль непосредственно после головного модуля. После выполнения операций ввода/вывода, процесс извлек модули и закрыл поток.[64]64
  При закрытии потока все встроенные модули извлекаются автоматически.


[Закрыть]

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

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

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

#include

#include

#include

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

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

Синхронизацию осуществляет головной модуль. Когда процесс выполняет системный вызов ioctl(2), который может быть обработан самим головным модулем, последний выполняет все операции в контексте процесса, и никаких проблем синхронизации и копирования данных не возникает. Именно так происходит обработка ioctl(2) для обычных драйверов устройств. Если же головной модуль не может обработать команду, он блокирует выполнение процесса и формирует сообщение M_IOCTL, содержащее команду и ее параметры, и отправляет его вниз по потоку. Если какой– либо модуль вниз по потоку может выполнить указанную команду, в ответ он направляет подтверждение в виде сообщения M_IOCACK. Если ни один из модулей и сам драйвер не смогли обработать команду, драйвер направляет вверх по потоку сообщение 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 – размер блока параметров команды,

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]65
  Расположение данных уже содержится в параметре arg, который передается обратно в сообщении M_COPYIN.


[Закрыть], необходимых для выполнения команды. Головной модуль пробуждает процесс, вызвавший ioctl(2), для копирования параметров. Поскольку последующие операции выполняются в контексте процесса, никаких проблем доступа к его адресному пространству не возникает. Головной модуль создает сообщение M_IOCARGS, копирует в него параметры команды и направляет сообщение вниз по потоку. После этого процесс опять переходит в состояние сна.

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

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

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

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

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

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

Рис. 5.23. Верхний мультиплексор

Нижний мультиплексор представляет собой драйвер псевдоустройства. Вместо работы с физическим устройством он взаимодействует с несколькими каналами вниз по потоку. Для этого нижний мультиплексор обеспечивает работу с еще одной парой очередей – нижними очередями чтения и записи. Структура streamtab нижнего мультиплексора адресует процедурный интерфейс работы с нижними очередями соответственно полями st_muxrinit и st_muxwinit.

Для работы с мультиплексированными потоками подсистема STREAMS поддерживает четыре команды ioctl(2):

I_LINK	Используется для объединения потоков. При этом файловый дескриптор указывает на поток, подключенный к мультиплексору. Второй файловый дескриптор, передаваемый в качестве аргумента команды, указывает на поток, который необходимо подключить ниже мультиплексора.
I_PLINK	Используется для потоков, которое сохраняется при закрытии файлового дескриптора. В остальном аналогично команде I_LINK.
I_UNLINK, I_PUNLINK	Используются для разъединения потоков, созданных командами I_LINK и I_PLINK.

Создание мультиплексированного потока происходит в два этапа. Поясним этот процесс на примере создания стека протокола IP, поддерживающего работу как с адаптером Ethernet, так и с адаптером FDDI. Для этого необходимо объединить драйвер адаптера Ethernet, драйвер адаптера FDDI и драйвер IP, который является нижним мультиплексором. Процесс должен выполнить следующие действия:

fdenet = open(«/dev/le», O_RDWR);

fdfddi = open(«/dev/fddi», O_RDWR);

fdip = open(«/dev/ip», O_RDWR);

ioctl(fdip, I_LINK, fdenet);

ioctl(fdip, I_LINK, fdfddi);

Сначала процесс создает три независимых потока, адресуемых дескрипторами fdenet, fdfddi и fdip (рис. 5.24, а) Для объединения потоков используется команда I_LINK системного вызова ioctl(2). В результате получается конфигурация, представленная на рис. 5.24, б.

Рис. 5.24. Создание мультиплексированного потока

В результате объединения потоков очереди и процедурный интерфейс головного модуля нижнего потока (в данном случае, потока, подключенного к драйверу Ethernet или FDDI), реализованный самой подсистемой STREAMS, заменяются на нижние очереди и соответствующий процедурный интерфейс мультиплексора. Более детально процесс объединения потока IP и потока Ethernet показан на рис. 5.25.

Рис. 5.25. Объединение верхнего и нижнего потоков

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

Заключение

Эта глава посвящена внутренней архитектуре подсистемы ввода/вывода, движущей силой которой являются драйверы устройств. Были рассмотрены традиционные типы драйверов, присутствующих в операционной системе UNIX с ранних ее версий, – символьные и блочные драйверы. Важную роль в процессе обмена данными с драйвером играют файловый интерфейс и файловая система.

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

Глава 6
Поддержка сети в операционной системе UNIX

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

Хотя многие версии UNIX сегодня поддерживают несколько сетевых протоколов, в этой главе мы подробнее остановимся на наиболее известном и распространенном семействе под названием TCP/IP. Эти протоколы были разработаны, а затем прошли долгий путь усовершенствований для обеспечения требований феномена XX века – глобальной сети Internet. Протоколы TCP/IP используются практически в любой коммуникационной среде, от локальных сетей на базе технологии Ethernet или FDDI, до сверхскоростных сетей ATM, от телефонных каналов точка-точка до трансатлантических линий связи с пропускной способностью в сотни мегабит в секунду.

Глава начинается с описания наиболее важных протоколов семейства TCP/IP – Internet Protocol (IP), User Datagram Protocol (UDP) и Transmission Control Protocol (TCP). Здесь описываются стандартная спецификация этих протоколов и особенности реализации их алгоритмов, не определенные стандартами, но позволяющие значительно повысить производительность работы в сети.

Далее обсуждается программный интерфейс доступа к протоколам TCP/IP. При этом рассматриваются два основных интерфейса – традиционный интерфейс работы с протоколами TCP/IP – интерфейс сокетов, изначально разработанный для системы BSD UNIX, и интерфейс TLI, позволяющий унифицированно работать с любыми сетевыми протоколами, соответствующими модели OSI. В конце раздела описан программный интерфейс более высокого уровня, позволяющий отвлечься от особенностей сетевых протоколов и полностью сосредоточиться на определении интерфейса и функциональности предоставляемых прикладных услуг. Эта система, которая называется RPC (Remote Procedure Call – удаленный вызов процедур), явилась предтечей современных систем разработки распределенных приложений, таких как CORBA (Common Object Request Broker), Java и т.д.

В последних разделах главы рассматривается архитектура сетевого доступа в двух основных ветвях операционной системы – BSD UNIX и UNIX System V.

Семейство протоколов TCP/IP

В названии семейства присутствуют имена двух протоколов – TCP и IP. Это, конечно, не означает, что данными двумя протоколами исчерпывается все семейство. Более того, как будет видно, названные протоколы выполняют различные функции и используются совместно.

В 1969 году Агентство Исследований Defence Advanced Research Projects Agency (DAPRA) Министерства Обороны США начало финансирование проекта по созданию экспериментальной компьютерной сети коммутации пакетов (packet switching network). Эта сеть, названная ARPANET, была построена для обеспечения надежной связи между компьютерным оборудованием различных производителей. По мере развития сети были разработаны коммуникационные протоколы – набор правил и форматов данных, необходимых для установления связи и передачи данных. Так появилось семейство протоколов TCP/IP. В 1983 году TCP/IP был стандартизирован (MIL STD), в то же время агентство DAPRA начало финансирование проекта Калифорнийского университета в Беркли по поддержке TCP/IP в операционной системе UNIX.

Основные достоинства TCP/IP:

□ Семейство протоколов основано на открытых стандартах, свободно доступных и разработанных независимо от конкретного оборудования или операционной системы. Благодаря этому TCP/IP является наиболее распространенным средством объединения разнородного оборудования и программного обеспечения.

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

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

□ В семейство TCP/IP входят стандартизированные протоколы высокого уровня для поддержки прикладных сетевых услуг, таких как передача файлов, удаленный терминальный доступ, обмен сообщениями электронной почты и т.д.