Сложный центр управления спутниками

1.                 Сложный центр управления спутниками

2.                 Спутники задевают верхние слои атмосферы, постепенно снижаются, затем падают на Землю. Живут один-два года.

Зато такие спутники дешевые и легкие.

Подсистемы ввода/вывода Файловые устройства

Цель любой программы – обработка данных, т.е. надо грамотно построить структуры данных и написать алгоритмы их обработки.

Структуры данных, которыми оперирует язык:

-           Array[] A

-           String B

-           Struct C

Можем прочитать откуда-то эти структуры:

read( #канала, A, B, C )

Отсюда исходят следующие действия:

read( #канала, Address, Len )

О длинах структур данных и куда их помещать знает только компилятор, следовательно, он и вычисляет Address и Len.

Файл может быть последовательного или произвольного доступа. В файле последовательного доступа есть так называемая текущая позиция.

Чтобы выполнить операции доступа к файлу, нужна начальная инициализация:

#канала = open( имя_файла, тип_доступа )

При открытии файла происходит следующее:

-           контролируются права доступа для данного пользователя с данным типом доступа

-           формируется структура FCB (File Control Block)

-           файловый процессор заполняет ее поля.

RMS (Record Management System)

По-русски – Система Управления Записями (СУЗ).

Она имеет FCB и буфера ввода/вывода, через которые и происходит реальный обмен данными.

RMS рассматривает любой файл как набор кластеров. Каждый кластер на уровне файла называется VBN (Virtual Block Number).

При закрытии файла ( close ) все буфера сбрасываются на диск. По команде Flush все буфера просто сбрасываются на диск без закрытия файла.

При необходимости обмена с диском RMS взаимодействует с файловым процессором.

Конкретное блочное устройство рассматривается как плоский массив блоков фиксированного размера.

Для символьных устройств нет буферов, но есть FCB, где содержатся параметры устройства.

При запросе ОС должна проверить указатели на корректность, т.е. указатель должен быть в области user’а и под ним должна быть отображена физическая память. Еще надо проверить, весь ли буфер попал в отображенную память.

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

Запросы ввода/вывода оформляются как IORP (Input/Output Request Packet). Поскольку к моменту выполнения запроса произойдет передиспетчеризация, то необходимо отобразить буфера ввода/вывода в ядро. Для этого производится двойное преобразование адреса:

1.       Преобразование линейного адреса буфера процесса в физический адрес.

2.       Отобразить в область ОС полученную область физической памяти.

Еще нужно запретить перемещение физических страниц памяти.

Монитор ввода/вывода должен по базе данных драйверов найти нужный драйвер, создать IORP в невыгружаемом пуле, поставить его в очередь к драйверу.

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

-      сложностью ОС

-      сложностью конфигурации железа.

Драйвер – программа, которая делает ОС независимую от железа.

Внешнее устройство – разделяемый ресурс, доступ к которому осуществляет драйвер.

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

База данных ввода/вывода

1.                 Устройства, которые отображаются в прикладные программы, называются Device.

2.  Устройства, которые не отображаются в прикладные программы, называются Bus.

3.  Потоковые драйверы/фильтры.

База данных – списки блоков управления CB (Control Block), которые отражают физическую структуру системы.

 

BCB	Bus Control Block
DCB	Device Control Block
UCB	Unit Control Block
ICB	Interrupt Control Block
SCB	Synchronization Control Block ?

IORP можно передать самому драйверу или поместить в очередь, прицепленную к DCB.

 

Преобразование ALBA ® FA ® KLBA может быть невозможно, т.к. страницы могут быть не выделены.

Стратегии организации последовательности IORP:

-                возлагается на ОС

-                драйвер сам решает, куда вставить IORP.

Если у драйвера очередь не пуста, то остается надеяться на обслуживание драйвером.

Вернуть управление программе, только если запрос был успешно обслужен (если запрос синхронный). Номер флага, который ожидает программа, помещается в IORP. Как только запрос выполняется – флаг сбрасывается и возобновляется программа, ожидавшая на этом флаге.

 

RPC	Remote Procedure Call
LPC	Local Procedure Call
APC	Asynchronous Procedure Call
DPC	отложенный

На DPC запрещена передиспетчеризация, на APC запрещена обработка асинхронных запросов, на Apps все разрешено.

Если очередь запросов пуста, то драйвер надо разбудить.

 

Проблема: из прерывания нельзя непосредственно вызвать IO$END, поскольку можем не находиться в режиме ядра.

Выход – механизм отложенных прерываний.

Механизм отложенных прерываний

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

Ядро не повторновходимо. Если мы владеем контекстом ядра, никто другой не может им владеть.

Единственное место, в котором начинается и заканчивается транзакция обращения к ядру – место переключения из UserMode в KernelMode. Только в этой точке передаются права на контекст ядра.

 

Ловушка отложенных прерываний

Для реализации используется XCHG AX,[BX], это семафор, реализованный на процессоре.

mov AX,1

xchg AX,[BX]

Если в результате в AX будет 0, то значит, семафор был свободен, и мы его заняли, а если 1 – значит был занят и надо еще подождать.

ОС вынимает из ловушки первый адрес и по call передает туда управление, когда управление вернется, ОС продолжает просмотр ловушки.

Мы можем завершить запрос ввода/вывода (выполнить соответствующие действия). Потом делаем jmp, как будто бы ОС заставила драйвер обработать новый запрос. Все будет так же, как и в первый раз, но после команды старт попадем опять на границу U/S.

Есть соблазн запихнуть в режим ядра как можно больше всего: работу с окнами, графикой, файловый процессор и т.д. для повышения быстродействия. Но тогда время обработки запросов приложений в режиме ядра будет слишком большим, а то и вообще система перестанет работать. Выход – идеология микроядра.

Идеология микроядра

Все сервисы работают в изолированных адресных пространствах. Если им что-нибудь надо, то они обращаются к микроядру.

Интерфейс заключается в пересечении границы. Одна граница – один интерфейс.

Если ЦП поддерживает всего два кольца защиты, то Супервизор тоже запихивают в Kernel Ring.

Итак, есть два интерфейса: Kernel|Supervisor и Supervisor|User. В супервизоре все процессы работают в своих адресных пространствах. Все проверки безопасности – на уровне супервизора.

В Windows2000 это сделано так.

Каждый модуль (FS, менеджер управления память, менеджер управления объектами и т.д.) запущен как отдельный поток со своим контекстом.

Драйвер может сам генерировать потоки, но его базовый поток – поток ядра.

GDI находится в супервизоре только с Win2000, раньше он был в Win32.exe. Без Win32.exe ни одно Win32-приложение работать не будет.

Синхронизация запросов ввода/вывода в ядре

У любого объекта Windows есть заголовок синхронизации, их можно ставить в очередь событий.

Процесс блокируется в ожидании некоторого события, которое ставится в очередь событий.

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

Запросы делятся на:

-                блокирующие

-                неблокирующие

В системах, поддерживающих неблокирующие запросы ввода/вывода, есть модификатор команд:

IO$READ + NoWait

Теперь возникает другая проблема – неблокирующий запрос выполнен, а как узнать, успешно ли он завершен? Это знает только драйвер.

Решение – в контексте задачи создается буфер IOSB (Input Output Status Block), в который драйвер помещает результаты выполнения операции. Это же происходит и при блокирующий запросах, но все это делается неявно.

Итак, для выполнения операции нужно следующее:

1.       Запрос (код операции, параметры)

2.       Координаты запроса (FCB, #LBN, длина)

3.       Адрес буфера

4.       IOSB

5.       Объект синхронизации.

Буферизованный и небуферизованный обмен

IORP – структура для хранения параметров запроса ввода-вывода. ОС копирует в этот пакет параметры из запроса QIO, которые хранятся в системе. Т.е. параметры в системном пуле и не […..]. Этими параметрами можно пользоваться. Если параметры типа указатель, то они имеют смысл только в контексте задачи. Если на процессоре наша задача, то в CR3 нужное страничное преобразование. Если на CR3 адрес ТСП другого приложения, то указатель будет неправильным. Поэтому драйвер не сможет выполнить обмен с буфером. Надо драйверу передать корректный указатель. Указатель должен существовать в контексте драйвера. Нужно получить новый логический адрес – в контексте драйвера. Нужно выяснить физический адрес буфера, полностью преобразовать его в логический адрес в контексте драйвера.

У драйвера контекст является контекстом, который совпадает с физической памятью. Т.е. там физический адрес совпадает с линейным. И этот адрес кладем в IORP. Поэтому нужно запретить перемещение и выгрузку – зафиксировать страницу. Также нужно запретить свопинг задач (выгрузка задачи полностью на диск).

Если таких задач много (зафиксировавшихся), то система начинает тормозить, и, в конце концов, падает.

Поэтому обмен между драйвером и буфером нужно делать через специальную область памяти – неперемещаемую.

Буферизованный обмен – это обмен через специальную область памяти – неперемещаемую. На самом деле при таком обмене существуют 2 буфера – один в неперемещаемой области памяти, второй в области приложения.

Запись: ОС заводит системный буфер, копирует туда буфер задачи, драйвер читает из буфера.

Чтение: ОС заводит буфер, драйвер пишет туда, ОС копирует из системного буфера в буфер приложения.

Это позволяет не ограничивать функции задачи.

Проблемы здесь в размерах. Например, по кластерам 128кБ на кластер.

Буферизованный обмен – для медленных, с небольшими буферами [устройств].

Небуферизованный – для быстрых и с большими буферами.

Запланированный ввод/вывод

Ничего нет.

Настройка ОС

На примере MS-DOS (система с начальной настройкой)

PnP – аппаратный интерфейс, служащий для динамической конфигурации и реконфигурации системы.

Этот механизм предполагает: