10.7. Графическая система Photon

Пользовательский интерфейс QNX строится на базе графической системы Photon. Структура графической системы представляет для нас интерес прежде всего потому, что она следует общим архитектурным концепциям QNX. Это обстоятельство делает графическую систему нетребовательной к ресурсам, легко масштабируемой - от интерфейса встроенного или карманного мобильного устройства до полнофункционального WIMP-интерфейса. Это обеспечивает также то, что возможные сбои графической системы не оказывают влияния на работоспособность всей ОС и требуют только перезапуска отказавшего компонента.

В отличие от других графических систем, которые обеспечивают функции графического интерфейса в монолитной (Windows) или клиент/серверной (X Window) модели, Photon строится на базе компактного графического микроядра и распределения графической функциональности между взаимодействующими процессами. Архитектура графической системы показана на рисунке 10.6, и она очень похожа на архитектуру QNX в целом.

Рисунок 10.6 Архитектура графической системы Photon

Микроядро Photon, которое является процессом QNX, выполняет необходимый минимум графических функций. Микроядро Photon занимает всего 55 Кбайт памяти. Прочие части графической системы - также процессы, которые для выполнения базовых функций обращаются к микроядру Photon, используя средства взаимодействия, обеспечиваемые микроядром QNX. Менеджеры графической системы являются опционными, включение новых менеджеров расширяет функции системы. До некоторой степени ключевым компонентом, определяющим переход от интерфейса встроенной системы к WIMP-интерфейсу, является менеджер окон, который обеспечивает изменение размера, минимизацию, перемещение и т.д. для окон.

Работа системы Photon строится на концепции "трехмерного пространства событий", которая иллюстрируется на рисунке 10.7.

Рисунок 10.7. Движение через пространство событий

Событиями в системе являются как события, инициируемые пользователем (мышью, клавиатурой), так и события, инициируемые процессами. Пространство, через которое движутся события, представляется как набор параллельно размещенных прямоугольных областей. Метафорой, давшей название системе, является движение частицы света (фотона) через ряд стеклянных пластин. На одном конце этого ряда находится корневая область, создаваемая системой, на другом конце - та область, которая представляется пользователю. Процесс, который выполняет какие-либо функции, связанные с интерфейсом, помещает свою область в этот ряд. Каждая область имеет две маски для проходящих через нее событий: маску чувствительности и маску непрозрачности. Установка бита чувствительности для определенного события определяет передачу события для обработки процессу, связанному с областью. Установка для события бита непрозрачности определяет прекращение движения события через пространство. Графические драйверы являются процессами, которые помещают свои области на переднем (ближнем к пользователю) краю ряда. Это обеспечивает также возможность распределенной обработки в сети: приложение с графическим интерфейсом может работать в одном узле сети, а результат его работы отображаться на другом узле. Физический драйвер целевого узел просто помещает свою область на переднем краю пространства событий. Подобным образом обеспечивается и отображение результатов работы приложений QNX в других графических системах: вместо драйвера в пространство событий вставляется область переходника в систему Windows или X Window.

АРХИТЕКТУРА ОПЕРАЦИОННОЙ СИСТЕМЫ UNIХ

Как уже ранее было замечено (см. [Christian 83], стр.239), в системе UNIX создается иллюзия того, что файловая система имеет "места" и что у процессов есть "жизнь". Обе сущности, файлы и процессы, являются центральными понятиями модели операционной системы UNIX. На Рисунке 2.1 представлена блок-схема ядра системы, отражающая состав модулей, из которых состоит ядро, и их взаимосвязи друг с другом. В частности, на ней слева изображена файловая подсистема, а справа подсистема управления процессами, две главные компоненты ядра. Эта схема дает логическое представление о ядре, хотя в действительности в структуре ядра имеются отклонения от модели, поскольку отдельные модули испытывают внутреннее воздействие со стороны других модулей.

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

На рисунке совокупность обращений к операционной системе разделена на те обращения, которые взаимодействуют с подсистемой управления файлами, и те, которые взаимодействуют с подсистемой управления процессами. Файловая подсистема управляет файлами, размещает записи файлов, управляет свободным пространством, доступом к файлам и поиском данных для пользователей. Процессы взаимодействуют с подсистемой управления файлами, используя при этом совокупность специальных обращений к операционной системе, таких как open (для того, чтобы открыть файл на чтение или запись),close, read, write, stat (запросить атрибуты файла), chown (изменить запись с информацией о владельце файла) и chmod (изменить права доступа к файлу). Эти и другие операции рассматриваются в главе 5.

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

Рисунок 2.1. Блок-схема ядра операционной системы

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

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

Примерами обращений к операционной системе, используемых при управлении процессами, могут служить fork (создание нового процесса), exec (наложение образа программы на выполняемый процесс), exit (завершение выполнения процесса), wait (синхронизация продолжения выполнения основного процесса с моментом выхода из порожденного процесса), brk (управление размером памяти, выделенной процессу) и signal (управление реакцией процесса на возникновение экстраординарных событий). Глава 7 посвящена рассмотрению этих и других системных вызовов.

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

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

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

Ядро Windows NT

"Сердцем" операционной системы Windows NT, работающим в тесной взаимосвязи с HAL, является ядро (или микроядро - microkernel). Ядро осуществляет диспетчеризацию нитей, обработку прерываний и исключительных ситуаций. Если компьютер имеет многопроцессорную архитектуру, ядро повышает производительность системы, синхронизируя работу процессоров. В мультипроцессорной конфигурации ядро может одновременно выполняться на всех процессорах. Роль ядра заключается в том, чтобы обеспечить оптимальную загрузку всех процессоров и наилучшую производительность системы. Для этого ядро осуществляет диспетчеризацию нитей в соответствии с их приоритетами. Фактически, оно принудительным образом проводит политику диспетчеризации, реализуемую модулем Windows NT Executive. Кроме того, ядро вытесняет (preempt) нити с низким приоритетом в пользу более высокоприоритетных нитей. Оно может принудительным образом выполнять переключения контекста (context switches), давая процессору инструкции прекратить выполнение одной задачи и взяться за другую. Таким образом, код, выполняющийся в такой системе, должен быть реентерабельным (reentrant). Под реентерабельностью кода понимается способность прервать выполнение и быть выгруженным, а также возобновить выполнение без потери информации. Кроме того, реентерабельный код может совместно использоваться несколькими различными нитями, выполняющими различные строки одного и того же кода на различных процессорах. Ядро является единственной неперемещаемой в памяти (nonpageable) и невыгружаемой (nonpreemptible) частью операционной системы. За редким исключением все остальные нити, работающие в Windows NT 4.0, в том числе и в составе модуля Executive, являются выгружаемыми (preemptible) и полностью реентерабельными. За счет этого достигается максимальная эффективность системы. Наконец, ядро синхронизирует деятельность таких сервисов Windows NT Executive, как Диспетчер ввода/вывода (I/O Manager) и Диспетчер процессов (Process Manager). Кроме того, компоненты Executive используют еще более высокие уровни абстракции, называемые объектами микроядра (microkernel objects), часть из которых экспортируется в пределах интерфейсных вызовов API с пользовательскими приложениями.

Общий обзор процесса

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

Основные этапы загрузки:

1. BIOS выполняет загрузочные шаги, специфичные для данного аппаратного обеспечения.

2. Когда все устройства распознаны и правильно запущены, BIOS загружает и выполняет загрузочный код с одного из разделов заданного загрузочного устройства, который содержит фазу 1 загрузчика Linux. Фаза 1 загружает фазу 2 (значительный по размеру код загрузчика). Некоторые загрузчики могут использовать для этого промежуточный этап (под названием фаза 1,5), поскольку современные диски большого объёма могут некорректно считываться без дальнейшего кода.

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

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

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

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

Когда происходит завершение работы, init вызывается для управляемого закрытия программ пользовательского уровня, тоже согласно сценариям. После этого init закрывается, а ядро производит свое собственное завершение работы.

Фаза загрузчика

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

• Для x86 или x86-64: код с загрузочного сектора раздела диска выполняется в реальном режиме и загружает первую фазу загрузчика (как правило — часть LILO или GRUB).

С этого момента загрузка продолжается. Первая фаза загружает остальной код загрузчика, который обычно спрашивает, какую операционную систему (или вид её сессии) пользователь хочет запустить. Код загрузчика создаётся на основе конфигурационного файла /etc/lilo.conf (для LILO), в котором определены доступные системы. Этот файл содержит, в частности, информацию о загрузочном разделе и расположении ядра для каждой из таких систем, а также дополнительные параметры загрузки, если они заданы. В результате выбора соответствующее ядро загружается в ОЗУ, минимальная начальная файловая система настраивается из файла-образа (initrd), а затем, вместе с соответствующими параметрами управление передаётся новой ОС.

LILO и GRUB имеют определённые различия:^[1]

• LILO не распознаёт файловые системы, поэтому он использует непосредственные (raw) смещения на диске и сведения из BIOS для загрузки данных. Он загружает код меню, а потом, в зависимости от выбора, загружает либо 512-байтные секторы диска для системы, основывающейся на MBR (например, Microsoft Windows), либо образ ядра для Linux.^[1]

• GRUB, наоборот, распознаёт распространённые файловые системы (например, ext2 и ext3).^[2] Так как GRUB хранит свои данные в файле конфигурации, а не в загрузочной записи, и имеет интерфейс командной строки, то зачастую параметры GRUB легче поправить или изменить, если они настроены неправильно или повреждены.^[3]

GRUB

Основная статья: GRUB

1. Загрузчик 1-й фазы считывается BIOS из MBR (главной загрузочной записи).^[4]

2. Он загружает оставшуюся часть загрузчика (2-ю фазу). Если вторая фаза находится на большом диске, иногда загружается промежуточная фаза 1,5, которая содержит дополнительный код, позволяющий считывать цилиндры с номерами более 1024 (диски LBA). Загрузчик фазы 1,5 хранится (если это необходимо) в MBR или в загрузочном разделе.^[4]

3. Выполняется вторая фаза загрузчика и отображает меню запуска GRUB. Оно также позволяет выбрать среду выполнения и просмотреть параметры системы.

4. Когда операционная система выбрана, она загружается и ей передаётся управление.^[4]

GRUB поддерживает и прямой, и цепной способ загрузки, а также LBA, ext2, и «истинно командно-ориентированную, дооперационную среду на машинах x86». Он имеет три интерфейса: меню выбора, редактор настроек и командную консоль.^[4]

LILO

Основная статья: LILO

LILO старше GRUB и практически аналогичен ему в действии, за исключением того, что не содержит интерфейса командной строки. Поэтому все изменения нужно вносить в его настройки и записывать в MBR, после чего систему перезагружают. Таким образом, ошибка в настройках может сделать диск неспособным к загрузке без использования отдельного загрузочного устройства (дискеты и т. п.), содержащего программу для исправления ошибки.^[3] Кроме того, LILO не распознаёт файловые системы; вместо этого, адреса файлов-образов хранятся непосредственно в MBR,^[3] а BIOS используется для прямого к ним доступа.

Loadlin

Основная статья: Loadlin

Ещё один способ загрузить Linux — из DOS или Windows 9x, где ядро Linux полностью заменит выполняющуюся копию операционной системы. Это может быть целесообразно, если аппаратное обеспечение должно включаться программно, а соответствующие программы существуют только для DOS, а не для Linux, будучи проприетарным ПО производителя и объектом коммерческой тайны. Этот метод загрузки не особо актуален, так как в Linux есть драйверы для множества аппаратных устройств, хотя в прошлом он был весьма полезен. Другой пример: когда Linux находится на устройстве хранения данных, которое не предназначено для загрузки из BIOS: DOS или Windows могут загрузить соответствующие драйверы, чтобы обойти такое ограничение BIOS, а затем загрузить оттуда Linux.

Фаза ядра

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

Этап загрузки ядра

Ядро при загрузке обычно имеет вид файла-образа, сжатого в формат zImage или bzImage с помощью zlib. В нём содержится головная программа, которая проводит минимальную настройку оборудования, распаковывает образ целиком в верхнюю память и монтирует RAM-диск, если он предусмотрен.^[5] После этого она выполняет запуск ядра посредством ./arch/x86/boot/head и процесса startup_32() (для процессоров семейства x86).

Этап запуска ядра

Источник: Описание процесса загрузки Linux фирмой «IBM»  (англ.) + переведённая версия с того же сайта Подробности процесса загрузки Linux  (рус.)

Функция запуска ядра (также называемая своппер или процесс 0) организует управление памятью (таблицы страниц и страничную организацию памяти), определяет тип процессора и дополнительные возможности (например, наличие математического сопроцессора), а затем переключается к архитектурно-независимому функционалу ядра Linux путём вызова start_kernel().

start_kernel() выполняет множество задач инициализации. Она настраивает обработчики прерываний (IRQ), затем настраивает память, запускает процесс init (первый процесс пользовательского режима), а затем запускает задачу бездействия вызовом cpu_idle(). Следует заметить, что процесс запуска ядра также монтирует инициирующий RAM-диск («initrd»), который ранее был загружен в роли временной корневой файловой системы в фазе загрузки. Это позволяет загружать модули драйверов, не опираясь на другие физические устройства и драйверы, и поддерживать небольшой размер ядра. Корневая файловая система впоследствии подменяется с помощью вызова pivot_root(), который размонтирует временную и заменяет её настоящей корневой ФС, как только последняя станет доступна. Использованная временной системой память затем освобождается.

Таким образом, ядро инициализирует устройства, монтирует указанную загрузчиком файловую систему в режиме «только чтение» и запускает процесс init (/sbin/init), который обозначается как первый процесс, запущенный системой (с идентификатором процесса PID = 1).^[1] Соответствующие сообщения выводит ядро (при монтировании файловой системы) и init (при запуске одноименного процесса). Ядро также может выполнить initrd для обработки настроек и инициализации устройств до монтирования корневой файловой системы.^[1]

По заявлению компании «Red Hat», детали процесса загрузки на этом этапе можно подытожить так:^[2]

Когда загружается ядро, оно сразу же инициализирует и конфигурирует память компьютера и настраивает различное подключённое к системе оборудование, включая все процессоры, подсистемы ввода-вывода и устройства хранения данных. Затем оно ищет сжатый образ initrd в заранее определённом участке памяти, распаковывает его, монтирует и загружает все необходимые драйверы. Затем оно инициализирует виртуальные устройства, связанные с файловой системой, например LVM или программные RAID-массивы, прежде чем демонтировать образ диска initrd и освободить всю память, ранее занимаемую образом. Потом ядро создает корневое устройство, монтирует корневой раздел только для чтения и освобождает всю неиспользованную память. К этому времени ядро загружено в память и работоспособно. Тем не менее, поскольку нет пользовательских программ для осуществления осмысленного ввода данных в систему, с ней мало что можно делать.

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

Процесс init (только типа UNIX System V)

Init является родителем всех процессов. Его главная задача — создавать процессы по сценарию из файла /etc/inittab. В этом файле обычно содержатся записи, указывающие init породить getty для каждой линии, по которой пользователи могут входить в систему. Он также контролирует автономные процессы, требуемые какой-либо системе. Уровень выполнения — программная конфигурация системы, которая позволяет существовать только заданной группе процессов. Процессы, порождаемые init на каждом из таких уровней выполнения, определяются в файле /etc/inittab.[6]

По сути init организует и поддерживает всё пользовательское пространство, что включает в себя также проверку и монтирование файловых систем, запуск нужных пользовательских служб и, переключение в пользовательскую среду, когда запуск системы завершится. Он похож на процессы init в Unix и BSD, от которых произошёл, но в некоторых случаях он изменён или переделан. В обычной системе Linux init имеет параметр, известный как уровень выполнения, принимающий значения от 1 до 6 и определяющий, какие подсистемы следует включить. Для каждого уровня выполнения есть собственные сценарии, которые регламентируют различные процессы, участвующие в установлении или снятии данного уровня, и именно эти сценарии считаются необходимыми для процесса загрузки. Сценарии init обычно хранятся в каталогах с именами вида /etc/rc…. Главный файл конфигурации уровней для init — /etc/inittab.^[7]

Во время загрузки системы он проверяет, описан ли уровень по умолчанию в /etc/inittab, а если же нет — запрашивает его через системную консоль. Затем он продолжает выполнять все соответствующие сценарии загрузки для этого уровня, включая загрузку модулей, проверку целостности файловой системы (которая монтировалась только для чтения), перемонтирование её для чтения-записи и настройку сети.^[1]

В частности, по сообщению Red Hat, процесс init следует такой схеме:^[2]

1. Он просматривает сценарий sysinit, который "устанавливает путь к среде, запускает swap, проверяет файловые системы и делает всё, что необходимо для инициализации системы. Это, в частности, системные и аппаратные часы, специальные процессы для последовательного порта и т. п.

2. Затем init просматривает конфигурацию, указанную для заданного уровня выполнения.

3. После этого init устанавливает исходную библиотеку функций для системы. Это определяет, как следует запустить или снять программу и как определить её PID.

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

После того, как он породил все заданные процессы, init переходит в режим ожидания и ждет одного из трёх событий:

1. Нормального или аварийного завершения порождённых процессов.

2. Сигнала аварии питания.

3. Запроса от /sbin/telinit на изменение уровня выполнения.^[6]

Это относится к программе init в стиле UNIX System V. Другие программы init могут вести себя иначе.

Прямой доступ к памяти (англ. Direct Memory Access, DMA) — режим обмена данными между устройствами компьютера или же между устройством и основной памятью без участия центрального процессора (ЦП). В результате скорость передачи увеличивается, так как данные не пересылаются в ЦП и обратно.

Кроме того, данные пересылаются сразу для многих слов, расположенных по подряд идущим адресам, что позволяет использование т. н. «пакетного» (burst) режима работы шины — 1 цикл адреса и следующие за ним многочисленные циклы данных. Аналогичная оптимизация работы ЦП с памятью крайне затруднена.

В оригинальной архитектуре IBM PC (шина ISA) был возможен лишь при наличии аппаратного DMA-контроллера (микросхема Intel 8237).

DMA-контроллер может получать доступ к системной шине независимо от центрального процессора. Контроллер содержит несколько регистров, доступных центральному процессору для чтения и записи. Регистры контроллера задают порт (который должен быть использован), направление переноса данных (чтение/запись), единицу переноса (побайтно/пословно), число байтов, которое следует перенести.

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

Контроллер может быть многоканальным, способным параллельно выполнять несколько операций.

Содержание

• 1 Захват шины (bus mastering)

• 2 DMA и виртуальная память, IOMMU и AGP GART

• 3 DMA и IDE/ATA, Ultra DMA

• 4 Режимы Ultra DMA протокола ATA для ОС Linux

Захват шины (bus mastering)

В шинах MicroChannel, SBus, разработанной под их большим влиянием PCI и её концептуальных производных AGP и PCI-X, используется иная реализация DMA. Эти шины позволяют любому устройству заявить о возникновении потребности к захвату шины, таковая потребность удовлетворяется т. н. арбитром при первой возможности. Устройство, успешно осуществившее захват шины, самостоятельно выставляет на шину сигналы адреса и управления и исполняет в течение какого-то времени ту же ведущую роль на шине, что и ЦП. Доступ ЦП к шине при этом кратковременно блокируется.

В такой реализации DMA не существует DMA-контроллера, а также номера входа DMA-контроллера.

Некоторые старые устройства PCI, а именно, реализации звуковых карт семейства Sound Blaster, использовали тот же DMA-контроллер 8237 из оригинальной архитектуры IBM PC. Такое использование является, безусловно, устаревшим для PCI, но поддерживалось с целью обеспечить полную совместимость по ПО и драйверам с версиями Sound Blaster для шины ISA.

Данная поддержка называется Distributed DMA (D-DMA) и реализована аппаратным образом как в устройстве, так и в логике моста PCI-ISA, в которой на PCI-системах размещена и логика оригинального IBM PC DMA контроллера 8237. Реализация включает в себя 2 запроса: сначала от устройства мосту PCI-ISA, затем от моста основной памяти.

Кроме упомянутых реализаций Sound Blaster, практически никакие устройства PCI не используют понятие «номер входа DMA-контроллера», как и 8237 вообще.

DMA и виртуальная память, IOMMU и AGP GART

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

Исполнение DMA по такому региону представляет собой довольно сложную задачу. Также сложной задачей является исполнение DMA по отгружаемой памяти.

Решение этой задачи требует выявления физических страниц, реализующих регион, и их блокировку от отгрузки обращением к подсистеме виртуальной памяти. Далее становится возможным нахождение физических адресов страниц региона, которые в общем случае не являются непрерывными и формируют так называемый «список рассеяния/сборки» (англ. scatter-gather list — SGL).

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

1. Выделение подряд идущей физической памяти в ядре операционной системы и промежуточное копирование всех данных туда/оттуда (т. н. «буфер отскока» — англ. bounce buffer).

Поддерживается всеми ведущими операционными системами, для активации поддержки в Windows требуется вызов IoGetDmaAdapter с параметром DEVICE_DESCRIPTION::ScatterGather, установленном в FALSE.

Недостатки: трата времени процессора на копирование, потребление крайне ограниченного ресурса непрерывной физической памяти, занятие места в ограниченной части памяти, к которой есть доступ у DMA (первый гигабайт на x86).

2. Разбиение операции на подоперации по границам элементов SGL, с прерыванием в конце каждой операции.

Использовалось в старых 8-битных SCSI-контроллерах, поставляемых со сканерами типа HP ScanJet.

Недостатки: большое количество прерываний.

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

Недостатки: крайне высокая сложность устройства, невысокая производительность большого числа записей в регистры.

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

Устройство читает SGL тем же механизмом DMA с захватом шины, что и собственно данные, тем самым реализуя функциональность некоего процессора, читающего и исполняющего свою собственную «программу», реализованную как список дескрипторов SGL. Данная архитектура называется «цепной DMA» (англ. chain DMA), реализована в практически всем стандартном оборудовании современного компьютера — Intel IDE (в примитивном виде), UHCI и OHCI USB, OHCI 1394, а также в большинстве PCI-адаптеров, Ethernet и SCSI (даже в устаревшем AIC78xx). Хороший пример реализации данной архитектуры в очень сложном и развитом виде дан в спецификации оборудования OHCI 1394. По некоторым сведениям, данная архитектура под названием «канальные программы» использовалась ещё в IBM 360, известных в СССР как ЕС ЭВМ.

Недостатки: высокая сложность устройства, хотя и ниже в числе транзисторов, чем предыдущий вариант. Например, контроллер UHCI USB (согласно спецификации на сайте Intel) требует около 5000 транзисторов.

5. Поддержка SGL в межшинном оборудовании, при которой представление физически разрывного буфера для стороны устройства выглядит физически непрерывным.

Таковое оборудование называется IOMMU (англ. IO memory management unit). Реализовывалось как на компьютерах фирмы Sun Microsystems для шины SBus, так и на компьютерах DEC Alpha для шины PCI. До недавних времен практически никогда не реализовывалось в обыкновенных x86/PCI системах, хотя в настоящее время есть тенденция к изменению этой ситуации, главным образом с целью повышения производительности гипервизоров виртуальных машин. Всегда реализовывалось для шины AGP под названием AGP GART с целью облегчить произвольный доступ трехмерного видеопроцессора к текстурам, находящимся в основной памяти. Со стороны устройства данное оборудование было стандартизировано спецификацией AGP, со стороны программного обеспечения стандартизации не существовало, и реализация зависела от производителя микросхемы северного моста между AGP и памятью (отсюда необходимость в «драйвере AGP», таком, как agp440.sys для микросхем Intel). Набор вызовов ядер развитых операционных систем, таких, как Windows, всегда содержал архитектурную абстракцию IOMMU (MapTransfer и GetScatterGatherList, эти же вызовы поддерживают и bounce buffer, понимаемый как разновидность IOMMU), позволяющую одному и тому же драйверу устройства поддерживать его при присоединении через различные IOMMU.

Недостатки: требование сложной логики уже не в устройстве, а в платформе.

DMA и IDE/ATA, Ultra DMA

Первоначальный контроллер жёсткого диска IBM PC/AT не поддерживал DMA, и требовал передачи всех данных дискового ввода-вывода инструкциями REP INSW/REP OUTSW через порт 0x1f0.

В начале 90-х годов диски MFM/RLL вымерли, сменившись дисками IDE, но регистровый интерфейс ПО к контроллеру не изменился.

Низкая производительность такого контроллера стала серьёзной проблемой, особенно на системах PCI. Помимо требования нескольких циклов PCI на 2 байта переданных данных, это приводило к загрузке процессора дисковым вводом-выводом.

Для решения проблемы ряд компаний, в том числе Intel, разработали контроллеры IDE с поддержкой DMA. Контроллеры были и есть несовместимы по ПО между различными производителями, хотя совместимость всех Intel IDE/ATA/SATA снизу вверх более или менее поддерживается.

Также особенностью этой поддержки является использование новых команд протокола IDE/ATA, а значит, и требование поддержки DMA не только контроллером, но и самим жёстким диском.

Около 2000 года поддержка DMA по шине IDE/ATA развилась в сторону увеличения тактовой частоты шины, что потребовало нового типа кабеля от контроллера к диску с удвоенным числом проводников меньшего размера. Эта технология называлась Ultra DMA (UDMA).

Многие операционные системы требовали действий администратора для использования IDE DMA. Так, например, стандартные ядра Linux до примерно 2004 года не имели такой поддержки, требовалось перестроение ядра с отредактированным файлом конфигурации.

В семействе Windows поддержка IDE DMA появилась сначала только для Intel в пакетах обновлений к Windows NT4, и требовала на большинстве систем ручного редактирования реестра для задействования.

В Windows 2000 это требование исчезло, но появилось требование обязательной вписки даже не-загрузочных дисков в BIOS и обязательного выставления режима DMA для них в настройках BIOS. Эти настройки BIOS становились видимы ядру ОС через технологию ACPI, и ОС не позволяла включить DMA для диска, не вписанного в BIOS. Для сравнения: NT4 поддерживала и произвольный размер диска, и DMA без вписки диска в BIOS.

В системах Linux для включения или выключения IDE DMA вручную может применяться команда hdparm (см. ниже). Современные версии ядра автоматически включают DMA режим, что можно наблюдать в сообщениях отладки (строки вида ata1.00: configured for UDMA/133 или hda: UDMA/33 mode selected).

Режимы Ultra DMA протокола ATA для ОС Linux

См. также: hdparm

# hdparm -i /dev/sda

…	MByte/s	…
Mode 0	16.7	UDMA16
Mode 1	25.0	UDMA25
Mode 2	33.3	UDMA33
Mode 3	44.4	UDMA44
Mode 4	66.7	UDMA66
Mode 5	100.0	UDMA100
Mode 6	133.3	UDMA133

Основные компоненты современной ВМ

Компьютеры могут быть более сложными и менее сложными, но некоторые их компоненты в принципе одинаковы. Они могут иметь различные размеры: от одной микросхемы до целых блоков величиной в несколько десятков сантиметров, состоящих из большого числа микросхем, однако функции этих компонентов остаются неизменными. Главная часть любого компьютера - его центральное процессорное устройство (ЦПУ), или просто центральный процессор (ЦП). По существу это - «мозг» машины, выполняющий инструкции и управляющий потоками информации в процессе ее обработки. Инструкции и данные, с которыми работает ЦП, хранятся в компьютерной памяти двух типов: постоянном запоминающем устройстве (ПЗУ) и оперативном запоминающем устройстве (ОЗУ; его также называют ЗУПВ - запоминающее устройство с произвольной выборкой). Содержимое ПЗУ неизменно и сохраняется при выключении машины. Информацию в ОЗУ можно изменять произвольным образом (например, при загрузке в машину программы из внешней памяти); она полностью уничтожается при отключении питания. Среди других компонентов, общих для всех компьютеров, назовем следующие: генератор тактовых импульсов, синхронизирующий внутренние операции (иногда он встроен в кристалл ЦПУ); шины - электронные схемы, соединяющие компоненты компьютера, и порты ввода-вывода. Также два дополнительных элемента: контроллер ввода-вывода и устройство прямого доступа к памяти (ПДП), которые встречаются не в каждом компьютере. Когда информация извне поступает в компьютер через порты, она идет по шинам к центральному процессору, который направляет ее далее в ОЗУ. В дальнейшем ЦП может извлечь эту информацию, чтобы обработать ее согласно указаниям (программе), хранящимся в памяти. Результаты обработки либо остаются в памяти, либо направляются через порты вывода на периферийное устройство, где они либо записываются на тот или иной носитель данных, либо преобразуются в те или иные операции. Здесь детально описаны три основных способа, которыми компьютер управляет вводом и выводом: опрашивание, прерывание и прямой доступ к памяти.

 

 

Основные компоненты компьютера Порты, через которые информация поступает в компьютер и выводится из него. Порты бывают входными, выходными и универсальными, совмещающими обе функции, а также последовательными и параллельными. Шины - это внутренние каналы для информации: управляющие сигналы проходят по шине управления; информация движется по шине данных по адресу, заданному сигналами с адресной шины. Тактовый генератор посылает регулярные электрические сигналы по шине управления, синхронизируя все внутренние операции компьютера. ПЗУ - постоянная внутренняя память компьютера, содержащая важную служебную информацию, например инструкции про граммы начальной проверки и загрузки. ОЗУ - временная память, где хранятся программы И данные, которые использует (и может изменять) ЦП. Центральный процессор (ЦП) - мозг компьютера, выполняющий все арифметические и логические операции. Контроллер ввода-вывода - дополнительное устройство, которое обычно применяется в больших системах, рассчитанных на много пользователей. Это устройство берет на себя управление некоторыми операциями по вводу-выводу, выполняемыми при его отсутствии центральным процессором. Контроллер ПДП - еще одно дополнительное устройство; может, минуя ЦП, обеспечить прямую связь между ОЗУ и периферийными устройствами.

 

 

Два способа управления вводом-выводом Управление процессом ввода данных в машину может осуществляться тремя способами. Основные этапы двух наиболее распространенных способов ввода-вывода опрашивание и прерывание приведенных здесь. При опрашивании центральный процессор проверяет (опрашивает) состояние каждого порта, определяя, поступила ли в него вводимая информация или готов ли он принять данные для последующего вывода. О состоянии порта сообщают обычно однобитные электронные сигналы, называемые флажками. Способ опрашивания прост, но это медленный процесс, на который расходуется ценное рабочее время ЦП, поскольку приходится каждый раз прерывать выполнение основной программы, чтобы опросить все порты - на тот случай, если потребуется отреагировать на определенное состояние какого-то из них. Это напоминает ситуацию, когда хозяин дома должен то и дело спускаться по лестнице и открывать парадную дверь, чтобы узнать, не пришел ли очередной гость. Способ ввода-вывода по прерыванию требует более сложных аппаратных и программных средств, но обеспечивает более эффективную работу процессора. При использовании этого способа процессор сосредоточен на выполнении своей основной функции - обработке данных. Когда порт готов к вводу или выводу, он посылает соответствующий сигнал - что-то вроде звонка в дверь - центральному процессору, который в данном случае лишь ненадолго прервет процесс обработки данных, чтобы обслужить порт, запросивший прерывания. Чтобы избежать путаницы при одновременном поступлении нескольких запросов на прерывание, для различных устройств устанавливаются разные уровни приоритета. Пользователь имеет возможность «замаскировать» (т. е. игнорировать) прерывания, за исключением одного - вызванного внезапным отключением питания. Это немаскируемое прерывание сообщает процессор, что у него есть в запасе всего несколько микросекунд на запоминание данных, пока не отключится вся система. Оба названных способа управления используются как для ввода, так и для вывода данных и не требуют какого либо специального контроллера ввода-вывода.

 

 

Прямой доступ к памяти На многих пригородных шоссейных дорогах имеются высокоскоростные полосы, по которым автомобилисты могут проноситься мимо еле двигающихся в часы пик потоков транспорта. Прямой доступ к памяти (ПДП) дает системам ввода-вывода компьютера аналогичное преимущество, ибо в этом случае данные мгновенно попадают в память и выводятся из нее без вмешательства центрального процессора, что потребовало бы больше времени. На самом деле часть функций процессора по управлению потоками информации в системе шин компьютера берет на себя контроллер прямого доступа к памяти. Такая «подмена» процессор может осуществляться несколькими способами. Чаще всего контроллер прямого доступа к памяти получает запрос на прерывание от периферийного устройства и посылает центральному процессору сообщение, что тот должен временно приостановить свои операции. процессор, ответив сигналом «подтверждение останова», временно уступает управление шинами и устраивает себе небольшую передышку. Тем временем контроллер прямого доступа к памяти прогоняет данные между оперативной памятью и устройствами ввода-вывода информации. Главное преимущество использования прямого доступа к памяти - быстродействие. В отличие от процессора, представляющего собой универсальное устройство, рассчитанное на решение разнообразных задач, контроллер прямого доступа к памяти выполняет лишь одну функцию, к которой и приспособлены его электронные схемы. Прямой доступ к памяти обычно используется при работе с такими периферийными устройствами, как терминалы с цветными графическими дисплеями, быстродействие которых слишком велико, чтобы центральный процессор мог эффективно управлять ими. ПДП играет полезную роль и при других операциях; например при загрузке в память информации с современных быстродействующих дисковых накопителей, выдающих информацию большими «плотноупакованными» порциями.

Понятие процесса и потока

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

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

Для описания столь сложного динамического объекта ОС поддерживает набор структур, главную из которых принято называть блоком управления процессом (PCB, Process control block). В состав PCB обычно включают:

• состояние, в котором находится процесс;

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

• содержимое регистров процессора;

• данные, необходимые для планирования использования процессора и управления памятью (приоритет процесса, размер и расположение адресного пространства и т. д.);

• учетные данные (идентификационный номер процесса, какой пользователь инициировал его работу, общее время использования процессора данным процессом и т. д.);

• информацию об устройствах ввода-вывода, связанных с процессом (например, какие устройства закреплены за процессом; таблица открытых файлов).

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

Потоки

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

Рис. 5.1. Процесс с несколькими потоками

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

Реализация процессов

Внутреннее устройство процессов в ОС Windows

В 32-разрядной версии системы у каждого процесса есть 4-гигабайтное адресное пространство, в котором пользовательский код занимает нижние 2 гигабайта (в серверах 3 Гбайта). В своем адресном пространстве, которое представляет собой набор регионов и описывается специальными структурами данных (см. часть III "система управления памятью"), процесс содержит потоки, учетную информацию и ссылки на ресурсы, которые обобществляются всеми потоками процесса.

Блок управления процессом (PCB) реализован в виде набора связанных структур, главная из которых называется блоком процесса EPROCESS. Соответственно, каждый поток также представлен набором структур во главе с блоком потока ETHREAD. Эти наборы данных, за исключением блоков переменных окружения процесса и потока (PEB и TEB), существуют в системном адресном пространстве. Упрощенная схема структур данных процесса показана на рис. 5.2.

Рис. 5.2. Управляющие структуры данных процесса

Содержимое блока EPROCESS подробно описано в [ Руссинович ] . Блок KPROCESS (на рис. справа), блок переменных окружения процесса (PEB) и структура данных, поддерживаемая подсистемой Win32 (блок процесса Win32), содержат дополнительные сведения об объекте "процесс".

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

Создание процесса

Обычно процесс создается другим процессом вызовом Win32-функции CreateProcess (а также CreateProcessAsUser и CreateProcessWithLogonW ). Создание процесса осуществляется в несколько этапов.

На первом этапе, выполняемом библиотекой kernel32.dll в режиме пользователя, на диске отыскивается нужный файл-образ, после чего создается объект "раздел" памяти для его проецирования на адресное пространство нового процесса.

На втором этапе выполняется обращение к системному сервису NtCreateProcess для создания объекта "процесс". Формируются блоки EPROCESS, KPROCESS и блок переменных окружения PEB. Менеджер процессов инициализирует в блоке процесса маркер доступа (копируя аналогичный маркер родительского процесса), идентификатор и другие поля.

На третьем этапе в уже полностью проинициализированном объекте "процесс" необходимо создать первичный поток. Это, посредством системного сервиса NtCreateThread, делает библиотека kernel32.dll.

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

Наконец, запускается первичный поток, для чего формируются его начальный контекст и стек, и выполняется запуск стартовой процедуры потока режима ядра KiThreadStartup. После этого стартовый код из библиотеки C/C++ передает управление функции main() запускаемой программы.

В книге [ Руссинович ] этапы создания процесса описаны более подробно.

Функция CreateProcess

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

BOOL CreateProcess(

PCTSTR pszApplicationName,

PTSTR pszCommandLine,

PSECURITY_ATTRIBUTES psaProcess,

PSECURITY_ATTRIBUTES psaThread,

BOOL bInheritHandles,

DWORD fdwCreate,

PVOID pvEnvironment,

PCTSTR pszCurDir,

PSTARTUPINFO psiStartInfo,

PPROCESS_INFORMATION ppiProcInfo);

Описание параметров функции можно посмотреть в MSDN.

Формально ОС Windows не поддерживает какой-либо иерархии процессов, например, отношений "родительский-дочерний". Однако, негласная иерархия, заключающаяся в том, кто чьим дескриптором (описателем) владеет, все же существует. Например, владение дескриптором процесса позволяет влиять на его адресное пространство и функционирование. В данном случае описатель дочернего процесса возвращается создающему процессу в составе параметра ppiProcInfo. Хотя он не может быть напрямую передан другому процессу, тем не менее, имеется возможность передать другому процессу его дубликат. Таким путем при необходимости в группе процессов может быть сформирована нужная иерархия.