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>
RtlGetNtProductType comes into two variants: one in user-mode that is exported for use from NTDLL layer and the kernel-mode that is used exclusively by the NT kernel. The kernel-mode variant of the function is not exported.
- Some "PartitionInfo->PartitionNumber = 0;" are ROS-specific hacks for
xHalIoAssignDriveLetters(), that should be fixed... Mark them as such.
- Un-hardcode some "magic" values (partition IDs, max number of
partition table entries, etc.).
- Use NULL instead of '0' for null-pointers.
- Fix some typos in comments.
Introduce the PiPerformSyncDeviceAction routine for queuing
synchronous device actions
Change all kernel code to use PiPerformSyncDeviceAction and
PiQueueDeviceAction for device enumeration
CORE-10456
Use single IOCTL (IOCTL_DISK_GET_DRIVE_GEOMETRY_EX) for retrieving
disk basic geometry information along with disk size.
Previous implementation used to issue two requests for that.
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
If SEH is used in a C trap handler, the exception frame will be
registered before the call to KiEnterTrap, which means we save
the wrong trap handler. We'll therefore also restore this wrong
frame for the excepting code, resulting in a stale SEH chain.
We avoid this problem by saving the handler in the assembly
trap entry code instead of from C. While SEH in a C trap handler
should now theoretically be safe, we still forbid it through
asserts in the C KiEnterTrap variants to make any potential
future problems more obvious. Should this functionality be
needed at some point and deemed safe, these asserts can then be
removed.
