Главная Обратная связь

Дисциплины:

Архитектура (936)
Биология (6393)
География (744)
История (25)
Компьютеры (1497)
Кулинария (2184)
Культура (3938)
Литература (5778)
Математика (5918)
Медицина (9278)
Механика (2776)
Образование (13883)
Политика (26404)
Правоведение (321)
Психология (56518)
Религия (1833)
Социология (23400)
Спорт (2350)
Строительство (17942)
Технология (5741)
Транспорт (14634)
Физика (1043)
Философия (440)
Финансы (17336)
Химия (4931)
Экология (6055)
Экономика (9200)
Электроника (7621)






Структура подсистемы ввода-вывода. Драйверы



Физические механизмы взаимодействия устройств ввода-вывода с вычислительной системой позволяют понять, почему разнообразные внешние устройства легко могут быть добавлены в существующие компьютеры. Все, что необходимо сделать пользователю при подключении нового устройства, – это отобразить порты устройства в соответствующее адресное пространство, определить, какой номер будет соответствовать прерыванию, генерируемому устройством, и, если нужно, закрепить за устройством некоторый канал DMA. Для нормального функционирования hardware этого будет достаточно. Однако мы до сих пор ничего не сказали о том, как должна быть построена подсистема управления вводом – выводом в операционной системе для легкого и безболезненного добавления новых устройств и какие функции вообще обычно на нее возлагаются.

Подсистема ввода-вывода в Microsoft Windows состоит из нескольких компонентов исполнительной системы, которые совместно управляют аппаратными устройствами и предоставляют интерфейсы для обращения к ним системе и приложениям.

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

ДРАЙВЕР [driver]. Управляющая программа. Обычно это программа операционной системы, обеспечивающая взаимодействие исполняемой программы с отдельным устройством и способствующая его удобному использованию. Например, существуют Д. клавиатуры, дисплея, мыши, принтера и т. п. Д. принимает запросы программ на обращение к устройству и преобразует их в команды управления устройством, а также обрабатывает прерывания от обслуживаемого устройства.

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

ДРАЙВЕР ВИРТУАЛЬНОГО УСТРОЙСТВА[virtual anything driver (VxD)]. Специальный класс драйверов, предоставляющий доступ к виртуальным устройствам, т.е. к устройствам, которые имитируются программным или аппаратным способом. Например, драйвер виртуального дисплея – программa, управляющая экраном дисплея. VxD – общее обозначение драйверов виртуальных устройств в операционных системах Windows. Так, драйвер виртуального дисплея обозначается VDD.



ДРАЙВЕР ЛОГИЧЕСКОГО УСТРОЙСТВА [type-specific driver (TSD)]. Драйвер, обслуживающий (в отличие от драйверов физических устройств) логические устройства, относящиеся к одному типу. Например, для работы со всеми жесткими дисками служит один драйвер, для работы со всеми гибкими дисками – др.

ДРАЙВЕР ПОРТА [port driver (PD)]. Компонент операционной системы, обеспечивающий доступ к портам устройства, подключенного к компьютеру. Д. п. зависит от конкретного типа и модели устройства. Например, для каждого дискового контроллера и накопителя используется отдельный Д. п.

ДРАЙВЕР ПРИНТЕРА [printer driver]. Драйвер, позволяющий приложениям корректно взаимодействовать с печатающим устройством, независимо от его типа и модели, а также используемого языкового интерпретатора.

ДРАЙВЕР-РУСИФИКАТОР[Cyrillic driver]. Драйвер, поддерживающий ввод в память компьютера и вывод на экран дисплея символов – букв русского алфавита (кириллицы). Д.-р. обычно является резидентной программой, которая активизируется нажатием командной клавиши (либо сочетания клавиш), служащей командой смены латинского алфавита на русский.

ДРАЙВЕР УСТРОЙСТВА[device driver]. Драйвер, позволяющий конкретному устройству, такому как модем, сетевая плата или принтер, взаимодействовать с операционной системой. Если устройство включено в список совместимого оборудования, то драйвер такого устройства обычно входит в состав операционной системы. Драйверы устройств загружаются автоматически (SYS-файлы) при запуске компьютера и с этого момента выполняются в режиме ядра, оставаясь невидимыми для пользователя. Драйверы устройств не работают с устройствами напрямую, а вызывают функции HAL.



ДРАЙВЕР ФАЙЛОВОЙ СИСТЕМЫ [file system driver (FSD)]. Компонент файловой системы, служащий для связи операционной системы с устройством длительного хранения данных (жестким или гибким диском). Кроме того, Д. ф. с. отвечает за поддержку длинных имен файлов и взаимодействие пользователя с конкретным устройством.

ПОРТ [port] – 1.Устройство сопряжения отдельных устройств (ЦП, ОЗУ и т.д.) с другими устройствами с целью передачи данных. Например, через П. подключаются к шине процессора устройства ввода/вывода, а программа может посылать данные в П. или получать данные из П. Обычно один и тот же П. может работать на ввод или вывод.

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


 

116. Функции подсистемы ввода-вывода.

 

Подсистема ввода-вывода в Windows должна предоставлять следующие функции:

· стандартные средства безопасности и именования устройств для защиты разделяемых ресурсов;

· высокопроизводительный асинхронный пакетный ввод-вывод для поддержки масштабируемых приложений;

· сервисы для написания драйверов устройств на высокоуровневом языке и упрощения их переноса между разными аппаратными платформами;

· поддержку многоуровневой модели и расширяемости для добавления драйверов, модифицирующих поведение других драйверов или устройств без внесения изменений в них;

· динамическую загрузку и выгрузку драйверов устройств, чтобы драйверы можно было загружать по требованию и не расходовать системные ресурсы без необходимости;

· поддержку Plug and Play (PnP), благодаря которой система находит и устанавливает драйверы для нового оборудования и выделяет им нужные аппаратные ресурсы;

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

· поддержку множества устанавливаемых файловых систем, в том числе FAT, CDFS (файловую систему CD-ROM), UDF (Universal Disk Format) и NTFS.

· поддержку Windows Management Instrumentation (WMI) и средств диагностики, позволяющую управлять драйверами и вести мониторинг за ними через WMI-приложения и сценарии.


 

117. Компоненты подсистемы ввода-вывода (структурная схема).

 

Для реализации этой функциональности подсистема ввода-вывода в Windows состоит из нескольких компонентов исполнительной системы и драйверов устройств (Рис 28):

· Центральное место в этой подсистеме занимает диспетчер ввода-вывода; он подключает приложения и системные компоненты к виртуальным, логическим и физическим устройствам, а также определяет инфраструктуру, поддерживающую драйверы устройств.

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

· Диспетчер РпР работает в тесном взаимодействии с диспетчером ввода-вывода и драйвером шины (bus driver) – одной из разновидностей драйверов устройств. Он управляет выделением аппаратных ресурсов, а также распознает устройства и реагирует на их подключение или отключение. Диспетчер РпР и драйверы шины отвечают за загрузку соответствующего драйвера при обнаружении нового устройства. Если устройство добавляется в систему, в которой нет нужного драйвера устройства, компоненты исполнительной системы, отвечающие за поддержку РпР, вызывают сервисы установки устройств, поддерживаемые диспетчером РпР пользовательского режима.

· Диспетчер электропитания, также в тесном взаимодействии с диспетчером ввода-вывода, управляет системой и драйверами устройств при их переходе в различные состояния энергопотребления.

· Процедуры поддержки Windows Management Instrumentation (WMI) (Инструментарий управления Windows), образующие провайдер WDM (Windows Driver Model) WMI, позволяют драйверам устройств выступать в роли провайдеров, взаимодействуя со службой WMI пользовательского Режима через провайдер WDM WMI.

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

· Для установки драйверов используются INF-файлы (файлы установки); они связывают конкретное аппаратное устройство с драйвером, который берет на себя ведущую роль в управлении этим устройством. Содержимое INF-файла состоит из инструкций, описывающих соответствующее устройство, исходное и целевое местонахождение файлов драйвера, изменения, которые нужно внести в реестр при установке драйвера, и информацию о зависимостях драйвера. В САТ-файлах хранятся цифровые подписи, которые удостоверяют файлы драйверов, прошедших испытания в лаборатории Microsoft Windows Hardware Quality Lab (WHQL).

· Уровень абстрагирования от оборудования (HAL – Hardware abstraction layer) изолирует драйверы от специфических особенностей конкретных процессоров и контроллеров прерываний, поддерживая API, скрывающие межплатформенные различия. В сущности HAL является драйвером шины для тех устройств на материнской плате компьютера, которые не контролируются другими драйверами.

Рис 28. Компоненты подсистемы ввода-вывода


 

118. Диспетчер ввода-вывода.

 

Диспетчер ввода-вывода (I/O manager) определяет модель доставки запросов на ввод-вывод драйверам устройств. Подсистема ввода-вывода управляется пакетами. Большинство запросов ввода-вывода представляется пакетами запросов ввода-вывода (I/O request packets, IRP), передаваемых от одного компонента подсистемы ввода-вывода другому. (Как вы еще убедитесь, исключением является быстрый ввод-вывод, при котором IRP не используется.) Подсистема ввода-вывода позволяет индивидуальному потоку приложения управлять сразу несколькими запросами на ввод-вывод.

IRP – структура данных, содержащая информацию, полностью опис-щую запрос в/в.

Диспетчер в/в создает IRP (представляющий операцию в/в), передает указатель на IRP соответствующему Д и удаляет пакет по завершении операции в/в.

Драйвер, получивший IRP, выполняет указанную в пакете операцию и возвращает IRP диспетчеру ввода-вывода, чтобы тот либо завершил эту операцию, либо передал пакет другому драйверу для дальнейшей обработки.

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

Диспетчер ввода-вывода также предоставляет гибкие сервисы ввода-вывода, на основе которых подсистемы окружения (например, Windows и POSIX) реализуют свои функции. В их число входят весьма изощренные сервисы асинхронного ввода-вывода, которые дают возможность разработчикам создавать высокопроизводительные масштабируемые серверные приложения.

Унифицированный модульный интерфейс драйверов позволяет диспетчеру ввода-вывода вызывать любой драйвер, ничего не зная о его структуре и внутреннем устройстве. Операционная система обрабатывает запросы на ввод-вывод так, будто они адресованы файлам; драйвер преобразует запросы к виртуальному файлу в запросы, специфичные для устройства. Драйверы также могут вызывать друг друга (через диспетчер ввода-вывода), обеспечивая многоуровневую независимую обработку запросов на ввод-вывод.


 

119. Типовая обработка ввода-вывода.

 

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

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

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


 

120. Установка драйвера.

 

Если диспетчер PnP встречает устройство, драйвер которого не установлен, он обращается к диспетчеру PnP пользовательского режима, и тот устанавливает нужный драйвер. Если устройство обнаруживается при загрузке системы, для него определяется узел устройств, но загрузка драйверов откладывается до запуска диспетчера PnP польз-кого режима (реализован в \Windows\System32\Umpnpmgr.dll и выполняется как сервис в процессе Services.exe).

Компоненты, участвующие в установке драйвера, показаны на Рис 29. Серые блоки на этом рисунке соответствуют компонентам, обычно предоставляемым системой, а остальные блоки – компонентам, предоставляемым установочными файлами (inf-файлы). Сначала драйвер шины информирует диспетчер PnP о перечисленном устройстве, сообщая его DIID (1). Диспетчер PnP проверяет, определен ли в реестре подходящий функциональный драйвер. Если Нет, он уведомляет диспетчер PnP польз-кого режима (2) о новом Устройстве, сообщая его DIID. Диспетчер PnP польз-кого режима Пытается автоматически установить драйверы для устройства.

DIID (Device Instance ID) – идентификатор экземпляра устройства – идентификатор, состоящий из идентификатора устройства и идентификатора экземпляра и используемый диспетчером PnP для поиска раздела для данного устройства в ветви реестра HKLM\SYSTEM\CurrentControlSet\Enum.

Если в процессе установки выводятся диалоговые окна, требующие внимания пользователя, а зарегистрированный в данный момент пользователь имеет привилегии администратора (3), то диспетчер PnP пользовательского режима запускает Rundll32.exe (хостпрограмму апплетов Control Panel) для выполнения мастера установки оборудования (\Windows\System32\Newdev.dll). Если заретстрированный в данный момент пользователь не имеет привилегий администратора (или в системе нет пользователей), а установка устройства требует взаимодействия с пользователем, диспетчер PnP польз-кого режима откладывает установку до того момента, когда в систему войдет привилегированный пользователь. Для поиска INF-файлов, соответствующих драйверам, совместимым с обнаруженным устройством, мастер установки оборудования использует API-функции Setup и CfgMgr (диспетчера конфигурации). При этом пользователю может быть предложено вставить в один из дисководов носитель с нужными INF-файлами; кроме того, просматриваются INF-файлы в \Windows\Driver Cache\i386\Driver.cab, где содержатся драйверы, поставляемые с Windows.

Чтобы найти драйверы для нового устройства, процесс установки получает от драйвера шины список идентификаторов оборудования (hardware ID) и идентификаторов совместимых устройств (compatible ID). Эти идентификаторы описывают все способы, предусмотренные в установочном файле драйвера (INF-файле) для идентификации устройства. Списки упорядочиваются так, чтобы наиболее специфические характеристики устройства описывались первыми. Если совпадения идентификаторов обнаруживаются в нескольких INF-файлах, предпочтение отдается наиболее полным совпадениям. Аналогичным образом предпочтение отдается INF-файлам с цифровой подписью, а среди них – более новым. Если найденный идентификатор соответствует идентификатору совместимого устройства, мастер установки оборудования может запросить носитель с обновленными драйверами для этого устройства.

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

Рис 29. Компоненты, участвующие в установке драйвера


 

121. Диспетчер электропитания.

 

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

• уровня активности системы;

• уровня заряда аккумуляторов;

• наличия запросов приложений на выключение компьютера или переход в ждущий/спящий режим;

• действий пользователя, например нажатия кнопки включения электропитания;

• параметров электропитания, заданных в Control Panel.

Часть информации, получаемой диспетчером PnP при перечислении устройств, связана с поддержкой устройствами функций управления электропитанием. Драйвер сообщает, поддерживает ли устройство состояния D1 и D2, а также какие задержки требуются ему для перехода из состояний D1-D3 в D0 (последняя часть данных необязательна). Чтобы диспетчеру было легче определять, когда систему следует переводить в другое состояние энергопотребления, драйверы шин также возвращают таблицу сопоставлений между системными состояниями (S0-S5) и состояниями, поддерживаемыми конкретным устройством. B этой таблице указывается состояние устройства с наименьшим энергопотреблением для каждого системного состояния. B таблице 9–4 показан пример таблицы сопоставлений для шины, поддерживающей все четыре возможных состояния устройств. Большинство драйверов полностью выключают свои устройства (D3) при выходе системы из состояния S0, чтобы свести к минимуму энергопотребление, пока машина не используется. Однако некоторые устройства вроде сетевых адаптеров поддерживают функцию вывода системы из состояний сна. O наличии подобной функции также сообщается при перечислении устройств.


122. СЕТЕВЫЕ ОПЕРАЦИОННЫЕ СИСТЕМЫ. НАЗНАЧЕНИЕ СЕТЕЙ

 

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

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

Одной из главных причин стала необходимость разделения ресурсов. Если в организации имеется несколько компьютеров и эпизодически возникает потребность в печати какого-нибудь текста, то не имеет смысла покупать принтер для каждого компьютера. Гораздо выгоднее иметь один сетевой принтер для всех вычислительных машин. Аналогичная ситуация может возникать и с файлами данных. Зачем держать одинаковые файлы данных на всех компьютерах, поддерживая их когерентность, если можно хранить файл на одной машине, обеспечив к нему сетевой доступ со всех остальных?

Второй причиной следует считать возможность ускорения вычислений. Здесь сетевые объединения машин успешно конкурируют с многопроцессорными вычислительными комплексами. Многопроцессорные системы, не затрагивая по существу строение операционных систем, требуют достаточно серьезных изменений на уровне hardware, что очень сильно повышает их стоимость. Во многих случаях можно добиться требуемой скорости вычислений параллельного алгоритма, используя не несколько процессоров внутри одного вычислительного комплекса, а несколько отдельных компьютеров, объединенных в сеть. Такие сетевые вычислительные кластеры часто имеют преимущество перед многопроцессорными комплексами в соотношении эффективность/стоимость.

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

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


Эта страница нарушает авторские права

allrefrs.ru - 2018 год. Все права принадлежат их авторам!