На 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 - аппаратный интерфейс, служащий для динамической конфигурации и реконфигурации системы.

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

1. сигнализацию о вставлении/удалении устройства

2. идентификацию устройств.

PnP не может осуществлять динамическую реконфигурацию самой ОС, а только внешних устройств.

Драйверы

- данный ресурс будет разделяемым

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

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

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

Драйверы устройств, не поддерживающих прерывания

Если устройство не генерирует прерывание, то точка входа драйвера по прерыванию цепляется к таймеру (для опроса) - polling.

Если READY = 1, то операция, запрошенная у ВУ завершена. Этот бит постоянно опрашивается (программно).

Если работаем в ВУ на прикладном уровне, то придется самим опрашивать регистры ВУ. В серьезных ОС прерывания на прикладном уровне недопустимы.

Файлы и файловые системы

В правилах есть постоянные и переменные параметры. Переменные параметры должны быть определены в метке тома. Ее положение - жестко заданная константа в любой ФС. Том - накопитель ФС.

Задачи ФС:

1. Оптимально разместить данные на носителе

2. Найти потом эти данные.

Необходимо присвоить каждому набору данных имя и дать возможность:

1. автору определить это имя

2. по имени найти набор данных

Сегментная ФС (на примере RT-11)

Файловые системы с глобальным индексом (FAT) решают проблему непрерывного хранения файлов. Теперь они могут располагаться кусками по всему носителю. Вся область хранения файлов разбивается на кластеры. Для нахождения файла, по-прежнему нужно знать только два числа - номер начального кластера и длину файла. Последовательность кластеров описывается списком - таблицей размещения файлов (FAT), которая состоит из записей, содержащих только номер следующего кластера (и записи соответственно). Каждый кластер соответствует определенной записи в таблице и наоборот. Если в записи 0, то значит кластер - свободен, если -1 - последний в цепочке.

Размер записи определяется количеством кластеров, так, чтобы можно было описать кластер с наибольшим номером.

UFS

Вместо индексного файла теперь индексные узлы - inode, размером в один сектор. Место выделяется блоками, их описание хранится в индексном файле. Метка тома теперь называется Суперблок. Создается связанный список свободных блоков. Нельзя сделать undelete, т.к. список портится.

S5FS

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

FFS (Fast File System) - файловая система BSD

Выделение логическими блоками. Идеологически - почти HPFS.

Индекс файла строится следующим образом:

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

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

С появлением сетей, единицей учета становится уже группа файлов, а не один файл.

NTFS

MFT2 - копия MFT сразу после форматирования.

Индекс уже описывает не файл, а некий набор данных, причем набор данных является множеством атрибутов. Каждый атрибут имеет имя и содержимое.

В одном индексе может описываться не один файл, а набор файлов. Файлы называются потоками - name : stream, где name - имя набора, stream - имя файла в наборе.

Например, все файлы БД можно поместить в один набор.

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

Access Control List (Список Управления Доступом) теперь можно хранить в индексе. Это массив ACEntry - структуры, которая описывает пользователя и группу и их права доступа.

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

NTFS - транзакционная файловая система. Любые операции по изменению ФС рассматриваются как транзакции.

log - файл журнала транзакций (всегда > 5 МБ). Это кольцевой буфер. Запись закрывается в момент закрытия транзакции. Если произошел сбой, то находятся все незакрытые записи и производится обратный откат.

В NTFS все - атрибуты, и файлы тоже.

Если файл маленький, то он записывается прямо в индекс.

Операция монтирования файлового устройства

Сетевые файловые системы

Модуль кэша ввода/вывода кэширует в первую очередь информацию каталогов, части индексных файлов и другую информацию ФП. Драйвер ФС имеет признак - локальная это ФС или удаленная.

Структура сетевых файловых систем.

Используются протоколы SAMBA (для локальных сетей) и ICFS (расширение SAMBA, поддерживающее маршрутизацию через Internet).

Недостаток таких систем - нельзя обеспечить большую емкость на каждой машине. А сейчас задача - хранение сверхбольших объемов данных. Два пути решения:

1. сделать сверхбольшие объемы дисков

2. подключать к локальной ФС удаленные ФС.

ASM - Application Storage Manager

NFS - Network File System

К каждому компьютеру подключается несколько дисков. Все это рассматривается как единая ФС.

NFS позволяет в любой каталог ФС локальной машины подключать любой фрагмент любой удаленной ФС.

Путь запроса O A B A O

Недостатки:

1. много передач между компьютерами

2. можно не найти файл, если администратор компьютера A перетащит подключение B в другой каталог.

NAS - Network Attached Storage

Добавляется сервер ФС, на котором хранится структура всей сети и все локальные каталоги. Любой запрос на чтение/запись сначала направляется на сервер, а потом перенаправляется туда, где действительно находятся данные.

Путь запроса O B O

Недостаток: сложно реализовать сервер ФС.

SAN - Storage Area Network

Fibre Channel - интерфейс, позволяющий подключать больше устройств, чем SCSI.

Идея:

Эта штука создает впечатление, что работа происходит с локальным SCSI устройством.

Fibre Channel использует оптоволоконные кабели, но это очень дорого.

Преимущества:

1. Скорость (около 1 Гб/с)

2. Поддержка SCSI.

iSCSI

Это протокол, поддерживающий SCSI интерфейс, но работающий с TCP/IP.

Страницы: 1, 2, 3, 4, 5, 6