"Легальный" deadlock при управлении питанием в W2K/XP

From

Gennady Mayko ()

To

Leo Yuriev ()

Date

2003-01-22T19:27:05Z

Area

SU.WINDOWS.NT.PROG

From: "Gennady Mayko" <gennady.mayko@broadcom.com>

Добрый день!

 LY> From: "Leo Yuriev" <ly@elcat.kg>

 GM>> From: "Gennady Mayko" <gennady.mayko@broadcom.com>

 GM>> --
 GM>> Я стараюсь так не делать и иметь только один "power policy owner"
 GM>> драйвер  в стеке драйверов, который отвечает за все "манипуляции" с
 GM>> "power" для  устройства (PCI платы), которым он управляет.

 LY> Конечно больше одного "power policy owner" это ненормально, но я все же
 LY> убежден что в этом нет ничего фатального. Точнее говоря два "power policy
 LY> owner" не создают каких-либо ситуаций, которые невозможно получить другим
 LY> способом, просто лишние IRP.

 LY> И стека драйверов тут получается как минимум два, один от BusPDO (который
 LY> под BusFDO), и второй от каждого ChildPDO и выше. Поэтому и "power policy
 LY> owner" должно быть два. Другое дело что BusFDO и все ChildPDO
 LY> обслуживаются одним драйвером.
--
Я немного порылся по Интернету и теперь (примерно) представляю конфигурацию
твоей платы и стек драйверов для нее. К сожалению, в моем случае конфигурация
была другой и, в некотором смысле, проще; несмотря на то, что мои платы
"физически" поддерживали DeviceState D2, они попадали в класс устройств,
которые должны поддерживать только DeviceState D0 и D3; это мое устройство не
могло "wake-up" систему.

Если бы я разрабатывал драйверы в твоей конфигурации, я бы сосредоточил все
управление device power management'ом или в ChildFDO (если я его разрабатываю
сам), или (если ChildFDO есть стандартный системный драйвер типа serial.sys),
то в драйвере-фильтре над (или под) этим стандартным ChildFDO. Я думаю, что
регистры PCI контроллера на плате, которые управляют power management'ом,
доступны только из BusFDO (или из ChildPDO), нет? Если да, то тогда всю
аппаратную поддержку "power management'a" я бы сделал в этом (этих) последнем
драйвере и сделал бы в них какой-нибудь приватный интерфейс, чтобы ChildFDO
(или драйвер-фильтр) смог асинхронно пользоваться соответствующим "power
management" сервисом. Но этот последний драйвер не являлся бы "power policy
owner'ом"!

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




 GM>> Насколько я понял, в описанном тобой случае эти 2 драйвера каким-то
 GM>> образом должны знать о состоянии друг друга и "договориться" о
 GM>> совместных  действиях в той или иной ситуации (например, после п.3
 GM>> BusFDO уже не  должен пытаться посылать запрос на PowerDeviceD3 или по
 GM>> крайней мере  должен его отложить до обработки уже запущенного).

 LY> Как я уже говорил для BusFDO и ChildPDO драйвер один, еще один драйвер
 LY> будет для ChildFDO. Причем этому драйвер будет (и должно быть) все равно
 LY> как работает его "шина".

 LY> Никакой синхронизации и/или взаимодействия не получается, потому что над
 LY> BusFDO и над ChildPDO может быть сколь угодно толстый "пирог" драйверов.
 LY> Иначе говоря ни BusFDO, ни ChildPDO не могут знать ли power-стек
 LY> "корреспондента" каким-либо IRP-запросом. Мне кажется это именно изян в
 LY> архитектуре управления питанием W2K/XP.
--
Почему не могут знать? По моему могут - ведь power management IRP всегда идут
"сверху вниз", т.е. первыми попадают к ChildPDO, а затем уже к BusFDO. Так что
теоретически можно сообщить BusFDO (еще до посылки ChildPDO драйвером IRP
"вниз"), что таки да обрабытываются power management IRP. Тем более, что, как
я понял, ChildPDO и BusFDO вообще "находятся" в одном драйвере.



 GM>> Нельзя ли IdleDetection перенести выше, в ChildPDO, так чтобы полностью
 GM>> избавить BusFDO от этого? Я понимаю, что это своеобразное "дублирование"
 GM>> и "размазывание" ответственности (потому что может быть несколько
 GM>> ChildPDO), но все же...

 LY> IdleDetection есть и в BusFDO, и в Child (но не в PDO, а в FDO). Никакого
 LY> дублирования нет, BusFDO отключается по таймауту неиспользования всех его
 LY> ChildPDOs, а в Child-стеках IdleDetection делает (или не делает)
 LY> FDO-драйвер.

 GM>> А какой шиной (bus) управляет BusFDO и чем управляют ChildPDO, если не
 GM>> секрет?

 LY> Я делаю драйвера с использованием своей библиотеки С++, в которой
 LY> частности реализован "образцовый" bus-драйвер. Поэтому это относится к
 LY> "универсальному" случаю. Последние "эксперименты" делаются на плате
 LY> Omega2-PCI, ChildPDO это memory-mapped COM-порты
 LY> (http://leo.yuriev.ru/SerialXP).

 LY> Взаимно.
 LY> Леонид.

С уважением,
Геннадий Майко.

--- ifmail v.2.15dev5
 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/400)