Введение в драйверы устройств ввода/вывода. Драйверы лекция


НОУ ИНТУИТ | Лекция | Введение в драйверы устройств ввода/вывода

Аннотация: В данной лекции основное внимание уделяется драйверам устройств ввода/вывода. Приводятся практические примеры и задачи для самостоятельного рассмотрения.

Эта телефонная система LG Electronics Voice over IP (VoIP) основывается на Windows Embedded CE. Фотография с разрешения Mike Hall.

Введение в драйверы устройств В/В

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

Большинство распространенных драйверов устройств поставляются вместе с ОС или доступны производителям микросхем, но многие нужно будет переносить на новую аппаратную платформу, так как даже небольшие изменения, такие как задание адреса порта В/В или уровня прерывания могут требовать небольших модификаций кода драйвера.

Одной из проблем, постоянно встречающейся разработчикам встроенных систем, является необходимость разработки драйверов устройств для уникального оборудования, вводимого при проектировании каждой новой платы. Документация по интерфейсам драйверов и примеры драйверов устройств поставляются с каждой ОС. Детали реализации драйверов варьируются от ОС к ОС. Может также поставляться инструмент типа мастера, помогающий сгенерировать шаблонный код, необходимый в новом драйвере устройства для правильного взаимодействия с ОС. В некоторых случаях драйверы устройств покупаются даже у сторонних разработчиков или разрабатываются внешними консультантами. Написаны целые книги по теме написания драйверов устройств. Библиотеки драйверов устройств CE перечислены в таблице 9.1.

Таблица 9.1. Библиотеки драйверов устройств CE Библиотека Описание
Собственные библиотеки микропроцессора Драйверы устройств для тесной интеграции собственных периферийных устройств микропроцессора. Например, микропроцессор ARM, и его дополнительная микросхема интегрирует многие периферийные устройства микропроцессора, такие как LCD, последовательный порт, USB Host, функцию USB, и т.д. SDB или аппаратная платформа, которая использует специальный микропроцессор будут использовать то же самое множество собственных драйверов микропроцессора. В Windows Embedded CE большинство микропроцессоров являются высоко интегрированными микропроцессорами, которые содержат много собственной периферии. Они связаны с так называемыми драйверами SOC (система-на-микросхеме) и находятся в ..\WINCE600 \Platform\Common\Src\SOC.
Специфические для микропроцессора библиотеки поддержки OAL Функции OAL для устройств, таких как часы реального времени, таймер, и контроллер отладки Ethernet, который обычно присутствует в микропроцессоре. Эта библиотека минимизирует написанный код OAL. Они также называются драйверами SOC (система-на-микросхеме) и находятся в ..\WINCE600 \Platform\Common\Src\SOC.
BSP или драйверы специфические для аппаратной платформы Драйверы устройств для периферии, которые являются специфическими для заданного SDB или аппаратной платформы. Эти драйверы имеют специфический для аппаратной платформы код и могут использоваться только на этой аппаратной платформе. Эти драйверы находятся в ..\WINCE600\Platform\<Hardware Platform Name> \Src\Drivers.
Другие распространенные драйверы периферийных устройств Драйверы для стратегических периферийных наборов микросхем, которые обычно встречаются во многих SDB или конструкциях аппаратных платформ. Сюда входят такие устройства как Realtek RTL8139, базовый NE2000, наборы микросхем DEC/Intel 2114x Ethernet, MediaQ MQ200, наборы микросхем дисплея ATI Rage XL, и наборы микросхем аудио Ensoniq. Цель состоит в том, чтобы предоставить драйверы производственного качества для 50% стратегических наборов микросхем, которые покрывают более 75% аппаратных платформ, доступных на рынке. Они называются общими драйверами и находятся в . .\WINCE600\Public\Common\Oak\Drivers. Исходный код для модулей находится в каталоге Public.
Модель потокового интерфейса для драйверов устройств

Драйвером1 с потоковым интерфейсом является любой драйвер, который предоставляет функции потокового интерфейса, независимо от типа устройства, которым управляет драйвер. Модель потокового интерфейса является простейшим способом реализации большинства драйверов пользователя, и приложения обращаются к ним с помощью обычных функций API файловой системы. Подобно многим свойствам ОС, подход на основе потокового интерфейса ведет свое начало из первых версий Unix.

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

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

Сами функции потокового интерфейса создаются таким образом, чтобы как можно ближе соответствовать семантике обычных интерфейсов прикладного программирования (API) файловых систем, таких как CreateFile, WriteFile, ReadFile, IOControl, и CloseHandle. В качестве побочного эффекта такого дизайна устройства, которые управляются потоковым интерфейсом, доступны для приложений через файловую систему; приложения взаимодействуют с драйвером, открывая специальные файлы в файловой системе.

Драйверы потокового интерфейса могут иметь монолитную архитектуру или архитектуру с двумя слоями, MDD и PDD, как показано на рисунке 9.1.

Две альтернативные архитектуры драйвера потокового интерфейса. Монолитный драйвер потокового интерфейса или Разделенный на слои драйвер потокового интерфейса. В разделенной на слои архитектуре драйвера в CE два слоя называются MDD и PDD Рис. 9.1. Две альтернативные архитектуры драйвера потокового интерфейса. Монолитный драйвер потокового интерфейса или Разделенный на слои драйвер потокового интерфейса. В разделенной на слои архитектуре драйвера в CE два слоя называются MDD и PDD

Интерпретация устройств как специальных файлов распространена во многих операционных системах, включая настольные версии Microsoft Windows и даже первые версия Unix. Там устройства печати традиционно представлялись именами специальных файлов LPTx:, а последовательные порты именами специальных файлов COMx:, и т.д.

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

В некоторых менее распространенных случаях драйверы потокового интерфейса могут переупаковывать существующие ресурсы, обычно таким образом, который специфические приложения смогут более легко использовать. Например, такой тип драйвера потокового интерфейса может управлять приемником системы глобального позиционирования (GPS) с последовательным интерфейсом. В этом примере ISV может выбрать создание специального драйвера потокового интерфейса для работы в соединении с приложением отображения GPS. Многие приемники GPS соединяются с последовательными портами. Приложение отображения GPS может, поэтому, открыть специальный файл COMx:, соответствующий последовательному порту и непосредственно взаимодействовать с приемником GPS.

Однако приемник GPS может предоставлять данные позиционирования в неудобном формате, или создатель приложения может захотеть сохранить скрытыми детали управления специальными моделями приемников GPS. Поэтому можно написать драйвер потокового интерфейса для обеспечения взаимодействия между приложением и приемником GPS. Драйвер будет взаимодействовать с приемником GPS как и раньше через специальный файл COMx:, но может переупаковывать данные позиционирования в более удобном формате для приложения. Драйвер может предоставлять свои собственные службы как специальный файл GPSx:, который будет открывать приложение, чтобы прочитать данные позиционирования.

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

Все драйверы потоковых интерфейсов, управляют ли они встроенными устройствами или устанавливаемыми устройствами, загружаются ли они во время начальной загрузки или загружаются динамически, имеют похожие взаимодействия с другими системными компонентами. Рисунок 9.2 показывает архитектуру драйверов потокового интерфейса для встроенных устройств, которые загружаются Device Manager во время начальной загрузки.

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

Можно реализовать драйвер только с точками входа Init и Deinit и без префикса устройства. Невозможно получить доступ к этому драйверу с помощью CreateFile. PCIBUS и RegEnum являются двумя примерами такого типа драйвера. Эти драйверы находятся в каталогах ..\WINCE600\Public\Common\OAK\Drivers\PCIbus и ..\WINCE600\Public\Common\ OAK\Drivers\RegEnum.

Архитектура потокового интерфейса Рис. 9.2. Архитектура потокового интерфейса

Если DEVFLAGS_NAKEDENTRIES определен в подключе реестра Flags драйвера, то имена точек входа могут быть лишены отличий; например, Open, Close, и т. д. Пример драйвера батареи, который находится в ..\WINCE600\Public\Common\OAK\Drivers\Battdrvr, является примером драйвера, который использует точки входа без отличий. Настройки реестра драйвера батареи должны тем не менее включать префикс.

Реализации этих точек входа должны объявляться для экспорта из DLL, размещая __declspec(dllexport) перед объявлением функции. При разработке в C++, точки входа должны также объявляться как внешние "C".

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

Таблица 9.2. Функции драйвера потокового интерфейса. Программный элемент Описание
XXX_Close Эта функция закрывает контекст устройства, определенный hOpenContext. Эта функция требуется для доступа к устройству с помощью CreateFile. Если вы реализуете XXX_Close, вы должны реализовать XXX_Open.
XXX_Deinit Эта функция де-инициализирует устройство. Ее вызывает Device Manager. Эта функция требуется драйверам, загружаемым ActivateDeviceEx, ActivateDevice, или RegisterDevice.
XXX_Init Эта функция инициализирует устройство. Ее вызывает Device Manager. Эта функция требуется драйверам, загружаемым ActivateDeviceEx, ActivateDevice, или RegisterDevice.
XXX_IOControl Эта функция посылает команду на устройство. Эта функция может требоваться или нет, в зависимости от возможностей устройства, которые предоставляет драйвер. Эта функция требует реализации XXX_Open и XXX_Close.
XXX_Open Эта функция открывает устройство для чтения, записи, или того и другого. Приложение неявно вызывает эту функцию, когда вызывает CreateFile для получения указателя на устройство. Эта функция требуется для доступа к устройству с помощью CreateFile.
XXX_PowerDown Не обязательная. Эта функция выключает питание устройства. Она будет полезна только с устройствами, которые можно выключить с помощью программного управления.
XXX_PowerUp Не обязательная. Эта функция восстанавливает питание в устройстве.
XXX_PreClose Не обязательная. Эта функция помечает закрывающий указатель как недействительный, и пробуждает все спящие потоки.
XXX_PreDeinit Эта функция помечает экземпляр устройства как недействительный и пробуждает спящие потоки. Эта функция требуется, если реализована функция XXX_PreClose.
XXX_Read Эта функция считывает данные из устройства, идентифицированного открытым контекстом. Эта функция может требоваться или нет, в зависимости от возможностей устройства, которые предоставляет драйвер. Эта функция требует реализации XXX_Open и XXX_Close.
XXX_Seek Эта функция перемещает указатель данных в устройстве. Эта функция может требоваться или нет, в зависимости от возможностей устройства, которые предоставляет драйвер. Эта функция требует реализации XXX_Open и XXX_Close.
XXX_Write Эта функция записывает данные в устройство. Эта функция может требоваться или нет, в зависимости от возможностей устройства, которые предоставляет драйвер. Эта функция требует реализации XXX_Open и XXX_Close.

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

Чтобы реализовать множественный доступ, каждый вызов функции XXX_Open должен возвращать различное значение для hOpenContext. Драйвер устройства должен отслеживать, какие возвращаемые значения из XXX_Open используются. Последующие обращения к XXX_Close, XXX_Read, XXX_Write, XXX_Seek, и XXX_IOControl передают эти значения назад драйверу устройства, позволяя драйверу идентифицировать, какими внутренними структурами данных манипулировать.

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

www.intuit.ru

Лекция №5. Структура драйвера. Основные точки входа. Точка входа DriverEntry.

Данная лекция может быть рассмотрена как одно большое оглавление последующих лекций.

На этой лекции будет рассмотрено:

  • Ограничения, налагаемые на драйвер

  • Точки входа драйвера. Описание наиболее общих точек входа драйверов ядра Windows NT. Будут указаны точки входа, которые должны быть реализованы обязательно, и точки входа, наличие которых зависит от назначения драйвера.

  • Назначение и взаимосвязь основных объектов. Прежде чем мы сможем обсуждать подробности каждой точки входа драйвера на следующих лекциях, важно понять общие концепции организации драйверов устройств Windows NT.

  • Точка входа DriverEntry

[5.1] Ограничения, налагаемые на драйвер

  • Драйвер режима ядра не может использовать API пользовательского уровня или стандартные библиотеки времени исполнения языка С. Можно использовать только функции ядра.

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

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

  • Код драйвер не должен долгое время работать на повышенных уровнях IRQL.

Другие ограничения можно посмотреть в [Developing Windows NT Device Driver, chapter 5, Driver Limitation]

[5.2] Назначение и взаимосвязь основных объектов

Рис. 1

Драйвер – это особый тип динамически подключаемой библиотеки (DLL). Фактически, это DLL, удовлетворяющая ряду дополнительных требований и меющая расширение “.sys”.

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

Когда происходит загрузка модуля? Это определяется соответствующими данному драйверу настройками в реестре (ключ Start). Как уже говорилось, этими настройками управляет Service Control Manager (SCM), хотя они могут быть изменены и вручную.

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

[5.2.1] Объект-драйвер

Объект-Драйвер описывает, где драйвер загружен в физическую память, размер драйвера и основные точки входа. Объект-драйвер создается диспетчером В/В и описывается частично документированной структурой данных DRIVER_OBJECT.

Примечание.

Microsoft не гарантирует неизменность недокументированных полей любых своих структур в последующих версиях ОС. Однако фактически, некоторые недокументированные в DDK элементы различных системных структур документированы в другом пакете для разработчика – IFS Kit.

Внутри функции DriverEntry происходит инициализация всего, что необходимо для выполнения драйвером его предназначения. В этой функции определяются стандартные и опциональные точки входа драйвера, в особенности – точки входа Dispatch, являющиеся частью структуры DRIVER_OBJECT. Кроме того, обычно именно здесь происходит создание одного или нескольких объектов-устройств.

studfiles.net

Драйверы устройств

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

1) перевод команд ОС в команды контроллера и обратно;

2) обмен данными между ОС и устройством через его контроллер.

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

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

  1. Лекция 4

    1. Понятие алгоритма

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

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

Термин «алгоритм» произошел от имени среднеазиатского ученого аль-Хорезми (787 – ок. 850), которым были описаны общие правила (названные позднее алгоритмами) выполнения основных арифметических действий в десятичной системе счисления. Эти алгоритмы изучаются в начальных разделах школьной математики. К числу алгоритмов школьного курса математики относятся также правила решения определенных видов уравнений или неравенств, правила построения различных геометрических фигур и т. п. Понятие алгоритма используется не только в математике, но и во многих областях человеческой деятельности, например, говорят об алгоритме управления производственным процессом, алгоритме управления полетом ракеты, алгоритме пользования бытовым прибором. Причем интуитивно под алгоритмом понимают некоторую систему правил, обладающих определенными свойствами.

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

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

2. Исполнитель может выполнить алгоритм, если он ему понятен, то есть записан на понятном ему языке и содержит предписания, которые исполнитель может выполнить. Набор действий, которые могут быть выполнены исполнителем, называется системой команд исполнителя. Алгоритм не должен содержать описания действий, не входящих в систему команд исполнителя, то есть своей структурой команд и формой записи алгоритм должен быть ориентирован на конкретного исполнителя.

3. Алгоритмы, предназначенные для исполнения техническим устройством, не должны содержать предписаний, приводящих к неоднозначным действиям. Алгоритм рассчитан на чисто механическое исполнение, и если применять его повторно к одним и тем же исходным данным, то всегда должен получаться один и тот же результат; при этом и промежуточные результаты, полученные после соответствующих шагов алгоритмического процесса, тоже должны быть одинаковыми. Это свойство определенности и однозначности – детерминированности  алгоритма позволяет использовать в качестве исполнителя специальные машины-автоматы.

4. Основополагающим свойством алгоритма является его массовость, применимость к некоторому классу объектов, возможность получения результата при различных исходных данных на некоторой области допустимых значений. Например, исходными данными в алгоритмах аль-Хорезми могут быть любые пары десятичных чисел. Конечно, его способ не всегда самый рациональный по сравнению с известными приемами быстрого счета. Но смысл массовости алгоритма состоит как раз в том, что он одинаково пригоден для всех случаев, требует лишь механического выполнения цепочки простых действий и при этом исполнителю нет нужды в затратах творческой энергии.

5. Цель выполнения алгоритма – получение конечного результата посредством выполнения указанных преобразований над исходными данными. В алгоритмах аль-Хорезми исходными данными и результатом являлись числа. Причем при точном исполнении всех предписаний алгоритмический процесс должен заканчиваться за конечное число шагов. Это обязательное требование к алгоритмам – требование их результативности или конечности.

В математике известны вычислительные процедуры алгоритмического характера, не обладающие свойством конечности. Например, процедура вычисления числа . Однако, если мы введем условие завершения вида «закончить после получения n десятичных знаков числа », то получим алгоритм вычисления n десятичных знаков числа . На этом принципе построены многие вычислительные алгоритмы.

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

studfiles.net

Лекция - Драйверы - Информатика

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

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

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

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

 

Рис. 7.5. Логическое расположение драйверов устройств

 

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

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

Драйвер устройства выполняет несколько функций:

1) обработку абстрактных запросов чтения и записи независи­мого от устройств и расположенного над ними программного обес­печения;

2) инициализацию устройства;

3) управление энергопотреблением устройства и регистрацией событий;

4) проверку входных параметров. Если они не удовлетворяют оп­ределенным критериям, драйвер возвращает ошибку. В противном случае драйвер преобразует абстрактные термины в конкретные. На­пример, дисковый драйвер может преобразовывать линейный номер блока в номера головки, дорожки и секторы;

5) проверку использования устройства в данный момент. Если ус­тройство занято, запрос может быть поставлен в очередь. Если уст­ройство свободно, проверяется его состояние. Возможно, требуется включить устройство или запустить двигатель, прежде чем начнется перенос данных. Как только устройство готово, может начинаться собственно управление устройством.

Управление устройством подразумевает выдачу ему серии ко­манд. Именно в драйвере и определяется последовательность команд в зависимости от того, что должно быть сделано. Определившись с командами, драйвер начинает записывать их в регистры контролле­ра устройства. Некоторые контроллеры способны принимать связные списки команд, находящихся в памяти. Они сами считывают и вы­полняют их без дальнейшей помощи операционной системы.

 

www.ronl.ru

Лекция 10

Лекция 10.

Задачи операционной системы по управлению файлами и устройствами. Многослойная модель подсистемы ввода-вывода. Менеджер ввода-вывода. Аппаратные и многоуровневые драйверы. Блок-ориентированные и байт-ориентированные драйверы. Подсистема ввода-вывода Windows. Обработка типичного запроса ввода-вывода в Windows. Типы драйверов Windows.

Одной из основных задач ОС является обеспечение обмена данными между приложениями и периферийными устройствами. В современной ОС функции обмена данными с периферийными устройствами выполняет подсистема ввода-вывода (Input-OutputSubsystem).

Основными компонентами этой подсистемы ввода-вывода являются драйверы, управляющие внешними устройствами, и файловая система. К подсистеме ввода-вывода можно также с некоторой долей условности и диспетчер прерываний, рассмотренный в Лекции 6.

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

  • организация параллельной работы устройства ввода-вывода и процессора;

  • согласование скоростей обмена и кэширование данных;

  • разделение устройств и данных между процессами;

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

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

  • динамическая загрузка и выгрузка драйверов;

  • поддержка нескольких файловых систем;

  • поддержка синхронных и асинхронных операций ввода-вывода.

Рассмотрим эти задачи.

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

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

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

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

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

Буферизация позволяет решать и другую задачу – сократить количество реальных операций ввода-вывода за счет кэширования данных.

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

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

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

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

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

Драйвер взаимодействует, с одной стороны, с модулями ядра ОС (модулями подсистемы ввода-вывода, системных вызовов, подсистем управления процессами и памятью и т.д.), а с другой стороны – с контроллерами внешних устройств. Поэтому существуют два типа интерфейсов: интерфейс «драйвер-ядро» (Driver Kernel Interface, DKI)и интерфейс«драйвер-устройство» (Driver Device Interface, DDI).DKIдолжен быть стандартизован в любом случае, аDDIимеет смысл стандартизировать тогда, когда подсистема ввода-вывода не разрешает драйверу непосредственно взаимодействовать с аппаратурой контроллера, а выполняет эти операции самостоятельно. Экранирование драйвера полезно, так как драйвер в этом случае становится независимым от аппаратной платформы. Подсистема ввода-вывода может поддерживать несколько различных типов интерфейсовDKI/DDI, предоставляя специфический интерфейс для устройств определенного класса.

Для поддержки процесса разработки драйверов операционной системы обычно выпускается так называемый пакет DDK (Driver Development Kit), представляющий собой набор соответствующих инструментальных средств – библиотек, компиляторов и отладчиков.

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

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

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

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

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

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

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

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

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

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

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

Еще одной функцией менеджера ввода-вывода является организация взаимодействия модулей ввода-вывода с модулями других подсистем ОС, таких как подсистема управления процессами, виртуальной памятью и другими.

В состав любой подсистемы ввода-вывода входят драйверы В традиционном смысле слова драйвер– это программный модуль, который:

  • входит в состав ядра операционной системы, работая в привилегированном режиме;

  • непосредственно управляет внешним устройством, взаимодействуя с его контроллером с помощью команд ввода-вывода компьютера;

  • обрабатывает прерывания от контроллера устройства;

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

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

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

Высокоуровневые драйверы оформляются по тем же правилам и придерживаются тех же внутренних интерфейсов, что и низкоуровневые драйверы. Единственным отличием является то, что высокоуровневые драйверы, как правило, не вызываются по прерываниям, так как взаимодействуют с управляемым устройством через посредничество аппаратных драйверов. Менеджер ввода-вывода управляет всеми драйверами однотипно, независимо от их уровня.

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

В унификацию драйверов большой вклад внесла операционная система UNIX. В ней все драйверы были разделены на два больших класса:блок-ориентированные (block-oriented) драйверыибайт-ориентированные (character-oriented) драйверы. Блок-ориентированные драйверы управляют устройствами прямого доступа, которые хранят информацию в блоках фиксированного размера, каждый из которых имеет свой собственный адрес. Самое распространенное внешнее устройство прямого доступа – диск.

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

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

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

Подсистема ввода-вывода в Windowsсостоит из нескольких компонентов исполнительной системы и драйверов устройств (рис. 10.2).

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

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

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

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

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

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

  • Для установки драйверов используются INF-файлы; они связывают конкретное аппаратное устройство с драйвером, который берет на себя ведущую роль в управлении этими устройством. СодержимоеINF-файла состоит из инструкций, описывающих соответствующее устройство, исходное и целевое местонахождение файлов драйвера, изменения, которые нужно внести в реестр при установке драйвера, и информацию о зависимостях драйвера. ВCAT-файлах хранятся цифровые подписи, которые удостоверяют файлы драйверов, прошедших испытания в лабораторииMicrosoftWindowsHardwareQualityLab.

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

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

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

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

  • Драйверы виртуальных устройств (virtual device drivers, VDD).Используются для эмуляции 16-разрядных программMS-DOS. Они перехватывают обращения таких программ к портам ввода-вывода, передаваемые реальным драйверам устройств. ПосколькуWindowsявляется полностью защищенной операционной системой, программыMS-DOSпользовательского режима не могут напрямую обращаться к аппаратным средствам – они должны это делать через драйверы устройств режима ядра.

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

Рис. 10.3. Схема обработки типичного запроса на ввод-вывод в Windows

Драйверы режима ядра можно разбить не несколько основных категорий:

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

  • PnP драйверы.Драйверы, работающие с оборудованием и интегрируемые с диспетчерами электропитания иPnP. В их число входят драйверы для устройств массовой памяти, видеоадаптеров, устройств ввода и сетевых адаптеров.

  • Драйверы, не отвечающие спецификации Plug and Play.Также называются расширениями ядра. Расширяют функциональность системы, предоставляя доступ из пользовательского режима к сервисам и драйверам режима ядра. Они не интегрируются с диспетчерамиPnPи электропитания. К ним, в частности, относятся драйверы протоколов и сетевогоAPI.

studfiles.net

Драйверы устройств

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

1) перевод команд ОС в команды контроллера и обратно;

2) обмен данными между ОС и устройством через его контроллер.

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

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

  1. Лекция 5

    1. Понятие алгоритма

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

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

Термин «алгоритм» произошел от имени среднеазиатского ученого аль-Хорезми (787 – ок. 850), которым были описаны общие правила (названные позднее алгоритмами) выполнения основных арифметических действий в десятичной системе счисления. Эти алгоритмы изучаются в начальных разделах школьной математики. К числу алгоритмов школьного курса математики относятся также правила решения определенных видов уравнений или неравенств, правила построения различных геометрических фигур и т. п. Понятие алгоритма используется не только в математике, но и во многих областях человеческой деятельности, например, говорят об алгоритме управления производственным процессом, алгоритме управления полетом ракеты, алгоритме пользования бытовым прибором. Причем интуитивно под алгоритмом понимают некоторую систему правил, обладающих определенными свойствами.

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

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

2. Исполнитель может выполнить алгоритм, если он ему понятен, то есть записан на понятном ему языке и содержит предписания, которые исполнитель может выполнить. Набор действий, которые могут быть выполнены исполнителем, называется системой команд исполнителя. Алгоритм не должен содержать описания действий, не входящих в систему команд исполнителя, то есть своей структурой команд и формой записи алгоритм должен быть ориентирован на конкретного исполнителя.

3. Алгоритмы, предназначенные для исполнения техническим устройством, не должны содержать предписаний, приводящих к неоднозначным действиям. Алгоритм рассчитан на чисто механическое исполнение, и если применять его повторно к одним и тем же исходным данным, то всегда должен получаться один и тот же результат; при этом и промежуточные результаты, полученные после соответствующих шагов алгоритмического процесса, тоже должны быть одинаковыми. Это свойство определенности и однозначности – детерминированности  алгоритма позволяет использовать в качестве исполнителя специальные машины-автоматы.

4. Основополагающим свойством алгоритма является его массовость, применимость к некоторому классу объектов, возможность получения результата при различных исходных данных на некоторой области допустимых значений. Например, исходными данными в алгоритмах аль-Хорезми могут быть любые пары десятичных чисел. Конечно, его способ не всегда самый рациональный по сравнению с известными приемами быстрого счета. Но смысл массовости алгоритма состоит как раз в том, что он одинаково пригоден для всех случаев, требует лишь механического выполнения цепочки простых действий и при этом исполнителю нет нужды в затратах творческой энергии.

5. Цель выполнения алгоритма – получение конечного результата посредством выполнения указанных преобразований над исходными данными. В алгоритмах аль-Хорезми исходными данными и результатом являлись числа. Причем при точном исполнении всех предписаний алгоритмический процесс должен заканчиваться за конечное число шагов. Это обязательное требование к алгоритмам – требование их результативности или конечности.

В математике известны вычислительные процедуры алгоритмического характера, не обладающие свойством конечности. Например, процедура вычисления числа . Однако, если мы введем условие завершения вида «закончить после получения n десятичных знаков числа », то получим алгоритм вычисления n десятичных знаков числа . На этом принципе построены многие вычислительные алгоритмы.

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

studfiles.net

Драйверы устройств

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

1) перевод команд ОС в команды контроллера и обратно;

2) обмен данными между ОС и устройством через его контроллер.

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

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

  1. Лекция 5

    1. Понятие алгоритма

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

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

Термин «алгоритм» произошел от имени среднеазиатского ученого аль-Хорезми (787 – ок. 850), которым были описаны общие правила (названные позднее алгоритмами) выполнения основных арифметических действий в десятичной системе счисления. Эти алгоритмы изучаются в начальных разделах школьной математики. К числу алгоритмов школьного курса математики относятся также правила решения определенных видов уравнений или неравенств, правила построения различных геометрических фигур и т. п. Понятие алгоритма используется не только в математике, но и во многих областях человеческой деятельности, например, говорят об алгоритме управления производственным процессом, алгоритме управления полетом ракеты, алгоритме пользования бытовым прибором. Причем интуитивно под алгоритмом понимают некоторую систему правил, обладающих определенными свойствами.

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

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

2. Исполнитель может выполнить алгоритм, если он ему понятен, то есть записан на понятном ему языке и содержит предписания, которые исполнитель может выполнить. Набор действий, которые могут быть выполнены исполнителем, называется системой команд исполнителя. Алгоритм не должен содержать описания действий, не входящих в систему команд исполнителя, то есть своей структурой команд и формой записи алгоритм должен быть ориентирован на конкретного исполнителя.

3. Алгоритмы, предназначенные для исполнения техническим устройством, не должны содержать предписаний, приводящих к неоднозначным действиям. Алгоритм рассчитан на чисто механическое исполнение, и если применять его повторно к одним и тем же исходным данным, то всегда должен получаться один и тот же результат; при этом и промежуточные результаты, полученные после соответствующих шагов алгоритмического процесса, тоже должны быть одинаковыми. Это свойство определенности и однозначности – детерминированности  алгоритма позволяет использовать в качестве исполнителя специальные машины-автоматы.

4. Основополагающим свойством алгоритма является его массовость, применимость к некоторому классу объектов, возможность получения результата при различных исходных данных на некоторой области допустимых значений. Например, исходными данными в алгоритмах аль-Хорезми могут быть любые пары десятичных чисел. Конечно, его способ не всегда самый рациональный по сравнению с известными приемами быстрого счета. Но смысл массовости алгоритма состоит как раз в том, что он одинаково пригоден для всех случаев, требует лишь механического выполнения цепочки простых действий и при этом исполнителю нет нужды в затратах творческой энергии.

5. Цель выполнения алгоритма – получение конечного результата посредством выполнения указанных преобразований над исходными данными. В алгоритмах аль-Хорезми исходными данными и результатом являлись числа. Причем при точном исполнении всех предписаний алгоритмический процесс должен заканчиваться за конечное число шагов. Это обязательное требование к алгоритмам – требование их результативности или конечности.

В математике известны вычислительные процедуры алгоритмического характера, не обладающие свойством конечности. Например, процедура вычисления числа . Однако, если мы введем условие завершения вида «закончить после получения n десятичных знаков числа », то получим алгоритм вычисления n десятичных знаков числа . На этом принципе построены многие вычислительные алгоритмы.

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

studfiles.net


Смотрите также