I’m saying that the contract on _DEP doesn’t say anything about when a driver is loaded, or even when a device is enumerated. The implementation in Windows 8 delays enumerating the dependent device until the depended-upon device is started. Some implementation like that is probably necessary for satisfying the actual contract on _DEP. But future versions of Windows may satisfy that contract differently, with driver-visible implications.
What this all boils down to is this: Using firmware to drive OS behavior is a bad idea, both because it’s not generally a low-precision strategy and because it’s fragile. You tend to be looking for side effects of the intended firmware interfaces, and side effects change.
In order to get a few platforms out the door in Windows 8, some people within Microsoft recommended the use of _DEP to those platform vendors. That may have been pragmatic on a short-term basis, for platforms where the firmware and the driver packages are very, very tightly tied. I think that recommending the strategy in general is asking for trouble.
- Jake Oshins
Windows Kernel Team
(sometime ACPI guy)
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Tuesday, November 27, 2012 6:53 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Driver load order questions
Again, acknowledging that I am not an ASL expert, or even journeyman really… and that Jake IS an ASL expert… I don’t wish to argue with the expert, but I don’t understand Jake’s reply.
Here’s the OP’s question:
Is A’s StartDevice guaranteed to be called before B’s StartDevice? If
not, is it possible to properly build ACPI DSDT/SSDT table to enforce that
order?
Are you saying that the ASL _DEP statement won’t do exactly what he’s asking?
This doesn’t say anything about driver load order but it does imply
something about device start order. This side effect is (mostly incidental) and
I suspect it may change in the future.
I don’t understand: WHICH side effect? Which driver is *loaded* first? I’m not sure that’s important in answering the OP’s question.
If DevA depends on DevB for power resources, the system can’t start DevA until DevB has been started… can it? IRP_MN_START_DEVICE signals an implicit transition to D0. So, the system can’t send the IRP_MN_START_DEVICE to DevA until he’s done so to DevB, right??
What am I missing?
Peter
OSR
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer