Андрей Робачевский - Операционная система UNIX
- Название:Операционная система UNIX
- Автор:
- Жанр:
- Издательство:BHV - Санкт-Петербург
- Год:1997
- Город:Санкт-Петербург
- ISBN:5-7791-0057-8
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Андрей Робачевский - Операционная система UNIX краткое содержание
Книга посвящена семейству операционных систем UNIX и содержит информацию о принципах организации, идеологии и архитектуре, объединяющих различные версии этой операционной системы.
В книге рассматриваются: архитектура ядра UNIX (подсистемы ввода/вывода, управления памятью и процессами, а также файловая подсистема), программный интерфейс UNIX (системные вызовы и основные библиотечные функции), пользовательская среда (командный интерпретатор shell, основные команды и утилиты) и сетевая поддержка в UNIX (протоколов семейства TCP/IP, архитектура сетевой подсистемы, программные интерфейсы сокетов и TLI).
Для широкого круга пользователей
Операционная система UNIX - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
Создание потока
Поток создается при первом открытии с помощью системного вызова специального файла устройства, ассоциированного с драйвером 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 драйвера указателями на процедурные интерфейсы очередей чтения и записи.
В завершение вызывается функция xx open()
драйвера. При последующих операциях открытия потока функция stropen()
последовательно вызовет функции xx open()
каждого модуля и драйвера, тем самым информируя их, что другой процесс открыл тот же поток, и позволяя разместить соответствующие структуры данных для обработки нескольких каналов одновременно. Обычно открытие потоков производится через драйвер клонов.
После открытия потока процесс может произвести встраивание необходимых модулей. Для этого используется системный вызов 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] При закрытии потока все встроенные модули извлекаются автоматически.
Поскольку модули описываются такими же структурами данных, что и драйверы, схемы их встраивания похожи. Как и в случае драйверов, для заполнения полей q_qinfo
структур queue используются данные из структуры streamtab
модуля. Для хранения информации, необходимой для инициализации модуля, во многих версиях UNIX используется таблица fmodsw[]
, каждый элемент которой хранит имя модуля и указатель на структуру streamtab
. После установления всех связей вызывается функция xx open()
модуля.
Управление потоком
Управление потоком осуществляется прикладным процессом с помощью команд системного вызова 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
:
Интервал:
Закладка: