Андрей Робачевский - Операционная система UNIX
- Название:Операционная система UNIX
- Автор:
- Жанр:
- Издательство:BHV - Санкт-Петербург
- Год:1997
- Город:Санкт-Петербург
- ISBN:5-7791-0057-8
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Андрей Робачевский - Операционная система UNIX краткое содержание
Книга посвящена семейству операционных систем UNIX и содержит информацию о принципах организации, идеологии и архитектуре, объединяющих различные версии этой операционной системы.
В книге рассматриваются: архитектура ядра UNIX (подсистемы ввода/вывода, управления памятью и процессами, а также файловая подсистема), программный интерфейс UNIX (системные вызовы и основные библиотечные функции), пользовательская среда (командный интерпретатор shell, основные команды и утилиты) и сетевая поддержка в UNIX (протоколов семейства TCP/IP, архитектура сетевой подсистемы, программные интерфейсы сокетов и TLI).
Для широкого круга пользователей
Операционная система UNIX - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
db_base |
Адрес начала буфера |
db_lim |
Адрес ячейки памяти, следующей непосредственно за буфером. Таким образом, размер буфера равен db_lim - db_base |
db_type |
Тип сообщения |
db_ref |
Число заголовков сообщения, адресующих этот блок |
Использование этих структур данных для формирования очереди сообщений и сообщений, состоящих из нескольких частей, показано на рис. 5.17.
Рис. 5.17. Сообщения STREAMS
Поле b_contзаголовка сообщения позволяет объединять несколько блоков данных в одно сообщение. Эта возможность особенно полезна при использовании подсистемы STREAMS для реализации сетевых протоколов. Сетевые протоколы имеют уровневую организацию. По мере передачи данных вниз по потоку, каждый последующий модуль (реализующий протокол определенного уровня) добавляет собственную управляющую информацию. Поскольку протоколы верхнего уровня не имеют представления об архитектуре нижних, невозможно заранее зарезервировать необходимую память под сообщение. Вместо того чтобы изменять размер буфера данных сообщения, модуль может добавлять управляющую информацию в виде отдельных частей, связывая их с помощью указателя b_cont. Этот процесс, получивший название инкапсуляции данных , графически представлен на рис. 5.18.
Рис. 5.18. Инкапсуляция данных с использованием составных сообщений
Поле db_refзаголовка блока данных позволяет нескольким заголовкам сообщения совместно использовать один и тот же буфер. При этом происходит виртуальное копирование сообщения, каждая копия которого может обрабатываться отдельно. Как правило, такой буфер используется совместно только для чтения, хотя сама подсистема STREAMS не накладывает никаких ограничений, возлагая всю ответственность за обработку данных на модули потока.
В качестве примера виртуального копирования можно привести реализацию протокола TCP. Протокол TCP является надежным, т.е. данные считаются доставленными только после того, как от получателя поступит подтверждение. Это означает, что протокол должен хранить копии всех отправленных, но не подтвержденных сообщений. Вместо неэффективного физического копирования, производится виртуальное дублирование сообщения, одна копия которого затем передается вниз по потоку (модулю IP), а вторая сохраняется до получения подтверждения. После отправления сообщения драйвером сетевого адаптера, одна из копий будет уничтожена, что выразится в уменьшении поля db_refзаголовка блока данных, но сам блок данных сохранится, поскольку значение счетчика по-прежнему будет превышать 0. И только после получения подтверждения db_refстанет равным 0, и соответствующий буфер будет освобожден.
Типы сообщений
Каждое сообщение принадлежит определенному типу, определяющему назначение сообщения и его приоритет. В зависимости от типа сообщения попадают в одну из двух категорий: обычные сообщения и приоритетные сообщения. Категория определяет порядок, в котором сообщения будут обрабатываться соответствующей процедурой xx service(). Приоритетные сообщения всегда помещаются перед обычными сообщениями и потому обрабатываются в первую очередь.
В подсистеме STREAMS определены следующие типы обычных сообщений:
M_DATA |
Содержит обычные данные. Например, системные вызовы read(2) и write(2) осуществляют передачу данных в виде сообщений этого типа. |
M_PROTO |
Содержит управляющую информацию. Обычно сообщение этого типа содержит также несколько блоков типа M_DATA. С помощью системных вызовов 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и I_STR. Эти команды используются для создания мультиплексированных потоков. Последняя команда используется для управления модулями потока. |
M_SETOPTS |
Используется для задания различных характеристик головного модуля. |
M_RSE |
Зарезервировано для внутреннего использования. Модули и драйверы должны передавать его без изменений. |
Как мы увидим далее, на передачу обычных сообщений влияет механизм управления потоком данных, который может быть реализован модулями потока. Этот механизм не оказывает влияния на передачу приоритетных сообщений. Сообщения этой категории будут переданы следующему модулю, независимо от того, насколько заполнена его очередь. Эти сообщения обеспечивают основное взаимодействие между компонентами потока. Перечисленные ниже сообщения являются высокоприоритетными:
M_COPYIN |
Передается вверх по потоку головному модулю и указывает ему скопировать данные от процесса для команды ioctl(2) . Сообщение допустимо в интервале между получением сообщения M_IOCTLи сообщения M_IOCACKили M_IOCNAK. |
M_COPYOUT |
Передается вверх по потоку головному модулю и указывает ему передать данные, связанные с вызовом ioctl(2) , процессу. Сообщение допустимо в интервале между получением сообщения M_IOCTLи сообщений M_IOCACKили M_IOCNAK. |
M_ERROR |
Передается вверх по потоку головному модулю и указывает на возникновение ошибки вниз по потоку. Последующие операции с потоком будут заканчиваться ошибкой, за исключением системных вызовов close(2) и poll(2) . |
M_FLUSH |
При получении этого сообщения модуль должен очистить очередь (чтения, записи или обе) от сообщений. |
M_HANGUP |
Передается вверх по потоку головному модулю и указывает, что драйвер не может передавать данные, обычно из-за обрыва линии (связи с удаленным объектом). |
M_IOCACK |
Подтверждение предыдущего сообщения M_IOCTL. В ответ головной модуль возвратит необходимые данные процессу, сделавшему системный вызов ioctl(2) . |
M_IOCNAK |
Если выполнение команды ioctl(2) закончилось неудачей, это сообщение передается вверх по потоку головному модулю, в ответ на это последний возвратит процессу ошибку. |
M_PCPROTO |
Высокоприоритетная версия сообщения M_PROTO. |
M_PCSIG |
Высокоприоритетная версия сообщения M_SIG. |
M_PCRSE |
Зарезервировано для внутреннего использования в подсистеме. |
M_READ |
Сообщение передается вниз по потоку, когда от процесса поступает запрос на чтение, но в головном модуле отсутствуют данные. |
M_STOP |
Предписывает немедленно прекратить передачу. |
M_START |
Предписывает продолжить передачу после останова, вызванного сообщением M_STOP. |
Передача данных
Интервал:
Закладка:
