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

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

Поддержка Plug and Play требует взаимодействия на уровнях оборудования, драйверов устройств и операционной системы. Эта поддержка в Windows базируется на промышленных стандартах перечисления и идентификации подключенных к шинам устройств. Например, стандарт USB определяет способ самоидентификации устройств, подключенных к шине USB. Ha этой основе в Windows реализуются следующие возможности Plug and Play.

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

• Диспетчер PnP выделяет аппаратные ресурсы, собирая информацию о требованиях устройств к аппаратным ресурсам (прерывания, диапазоны адресов ввода-вывода, регистры ввода-вывода или ресурсы, специфичные для шин). B ходе арбитража ресурсов (resource arbitration) диспетчер PnP распределяет ресурсы между устройствами с учетом их требований. Поскольку устройства могут быть добавлены в систему после распределения ресурсов на этапе загрузки, диспетчер PnP должен уметь перераспределять ресурсы.

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

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

Windows нацелена на полную поддержку Plug and Play, но конкретный уровень поддержки зависит от устройств, подключенных к системе, и установленных в ней драйверов. Уровень поддержки Plug and Play может быть снижен, если хотя бы один драйвер или устройство не отвечает стандарту Plug and Play. Более того, драйвер, не поддерживающий Plug and Play может лишить систему возможности использовать другие устройства. B таблице 9–2 показано, к каким результатам приводят различные сочетания устройств и драйверов с поддержкой Plug and Play и без нее.

PnP-несовместимое устройство, например унаследованная звуковая плата с ISA-шиной, не поддерживает автоматическое определение. Из-за этого таким устройствам запрещены некоторые операции вроде «горячего» подключения или перехода в один из режимов сна. Если для такого устройства вручную установить РпР-совместимый драйвер, он сможет по крайней мере использовать ресурсы, которые диспетчер PnP будет выделять этому устройству.

Унаследованные драйверы, например драйверы, разработанные для Windows NT 4, не совместимы с Plug and Play. Хотя они работают в Windows, диспетчер PnP не сможет динамически перераспределять ресурсы, назначенные таким устройствам. Допустим, унаследованное устройство использует для ввода-вывода диапазон памяти A или В. При загрузке системы диспетчер PnP выделяет этому устройству диапазон А. Если впоследствии в систему будет добавлено устройство, способное использовать только диапазон А, диспетчер PnP не сможет указать драйверу первого устройства перенастроить его на диапазон В. Из-за этого второе устройство не получит нужные ресурсы и будет недоступно. Унаследованные драйверы также мешают переходу системы в один из режимов сна (см. раздел «Диспетчер электропитания» далее в этой главе).

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

Выполняя процедуру добавления устройства, функциональные драйверы и драйверы фильтров готовятся начать управление своими устройствами, но на самом деле пока еще не взаимодействуют с ними. Они ждут команду startdevice, которую диспетчер PnP должен передать их процедурам диспетчеризации Plug and Play. До передачи этой команды диспетчер PnP выполняет арбитраж ресурсов, чтобы решить, какие ресурсы выделить тому или иному устройству. B команде start-device указываются назначенные ресурсы, определенные диспетчером PnP при арбитраже ресурсов. Получив команду start-device, драйвер может настроить свое устройство на использование указанных ресурсов. Если программа пытается открыть устройство, которое не готово к началу работы, она получает код ошибки, указывающий на отсутствие этого устройства.

После запуска устройства диспетчер PnP может посылать драйверу дополнительные PnP-команды, в том числе относящиеся к удалению устройства из системы или перераспределению ресурсов. Например, когда пользователь запускает утилиту, показанную на рис. 9-23, — для ее запуска надо щелкнуть правой кнопкой мыши значок платы PC Card на панели задач и выбрать команду Unplug Or Eject Hardware (Отключение или извлечение аппаратного устройства), — и командует Windows извлечь PCMCIA-плату, диспетчер PnP посылает уведомление query-remove каждому приложению, зарегистрированному на получение PnP-уведомлений об этом устройстве. Как правило, приложения регистрируются на получение уведомлений через свои описатели устройства, которые они закрывают, получая уведомление query-remove. Если ни одно приложение не налагает вето на запрос query-remove, диспетчер PnP посылает команду query-remove драйверу, управляющему извлекаемым устройством. Ha этом этапе драйвер решает, что ему делать дальше: запретить удаление устройства или завершить все операции ввода-вывода на этом устройстве и прекратить дальнейший прием запросов на ввод-вывод, направляемых устройству. Если драйвер отвечает согласием на запрос об удалении и открытых описателей устройства больше нет, диспетчер PnP посылает драйверу команду remove, требующую от него прекратить обращение к устройству и освободить все ресурсы, выделенные им для данного устройства.