CmResourceTypeDevicePrivate resources are created the the bus driver, for its own later use,
when children devices will receive the IRP_MN_START_DEVICE.
Do not translate them, as they have no meaning outside bus driver.
- Change INIT_FUNCTION and INIT_SECTION to CODE_SEG("INIT") and DATA_SEG("INIT") respectively
- Remove INIT_FUNCTION from function prototypes
- Remove alloc_text pragma calls as they are not needed anymore
CORE-14037
- Fix buggy retrieval of the current calling Irp->Tail.Overlay.Thread.
- The 4th argument (KernelRoutine) to the KeInitializeApc() is **NOT**
optional; however its 5th argument (RundownRoutine) is.
So use the mandatory routine for freeing the allocated APC instead.
We don't use the rundown routine yet.
- Check whether the ExAllocatePoolWithTag() call failed or not before
queueing the allocated APC.
The current implementation of device tree enumeration does not distinguish
between possible identifier strings. This change is not a hack,
NT 5.2 still creates a new device node for this hardware ID.
The entire function should be rewritten to match Windows implementation.
We are doing IoCallDriver here, so the valid stack location should be
CurrentLocation <= Irp->StackCount (just a check for a completly incorrect value)
&& CurrentLocation > 1 (ensure that we have a place for another call)
CORE-17189
Co-authored-by: Thomas Faber <thomas.faber@reactos.org>
Introduce the PiPerformSyncDeviceAction routine for queuing
synchronous device actions
Change all kernel code to use PiPerformSyncDeviceAction and
PiQueueDeviceAction for device enumeration
CORE-10456
And rearrange them in more logical order.
This effectively splits the file, leaving public "Io" functions in
pnpmgr.c along with some things not related do device object management.
Functions which manipulate the device tree are left in devaction.c.
In future all these functions will only be accessed from
DeviceActionWorker.
While being public API, IoRequestDeviceEject and IoInvalidateDeviceState
have been moved to devaction.c as well. In next commits they will be
converted to DeviceActionWorker routines and their callers will be put
in pnpmgr.c
Useful functions for debugging IO and PNP managers:
PipDumpDeviceNodes() - displays information about a node(s) in the device tree;
PipDumpResourceRequirementsList() - displays information about a Io List;
PipDumpCmResourceList() - displays information about a Cm List
The tree list of devices (DEVICE_NODE structures) is perhaps the main one in the PnP manager. They also store information about the hardware resources required and assigned to devices.
These functions can help with debugging. For example, you can call PipDumpDeviceNodes() before and after device enumeration and compare the resulting information.
For PipDumpDeviceNodes() it is possible to optionally output:
- allocated resources and boot configuration resources
- resources required
- translated resources
It is possible to displays both a single node and the entire tree.
Optionally, you can display child nodes.
The information output format for resource lists is maximally compressed, since often the only debugging port is a monitor.
The DebugLevel parameter allows dumping in two modes:
0 - unconditional;
1 - if NDEBUG is not defined in "debug.c".
- Improve the device action worker to support more than just a single action
- Move the action queue code from IoInvalidateDeviceRelations to a new function IopQueueDeviceAction.
This also makes it necessary to fix a bug in the previous code:
ZwEnumerateKey will not account for space for a null terminator, so to
ensure we have space, we must allocate the additional WCHAR, but not
include it in the buffer size passed to the function.
- Windows requires 16 bytes of response data.
- Add the PLUGPLAY_CONTROL_USER_RESPONSE_DATA type.
- Usetup and Umpnpmgr must fail if NtPlugPlayControl(PlugPlayControlUserResponse) does not return STATUS_SUCCESS.
