Commit graph

11 commits

Author SHA1 Message Date
Victor Perevertkin 4c95339da0
[NTOS:IO] Refactoring of the driver initialization code (2)
- Do not hold the IopDriverLoadResource while trying to reference a
  driver object (but still acquire it when we actually need to load a
  driver)
- Change IopLoadDriver and IopInitializeDriverModule to use registry
  handle instead of a service name string and/or full registry path
- Do not try to reference a driver object inside IopLoadDriver. It's
  supposed to be done before the function call
2021-01-04 16:50:33 +03:00
Victor Perevertkin e18a32df3a
[NTOS:IO] Refactoring of the driver initialization code
- Remove IopCreateDriver and put its code into IoCreateDriver and
  IopInitializeDriverModule. It's hard to extract a meaningful common
  part from it
- Refactor IopInitializeDriverModule. Extend and put the DriverName
  generation logic into it. Now this function frees the ModuleObject in
  case of failure and returns STATUS_FAILED_DRIVER_ENTRY in case of
  DriverInit failure (will be used later)
2021-01-04 16:50:32 +03:00
Victor Perevertkin 6f0e37b042
[NTOS:PNP][NTOS:IO] Do not create a device object + node on every driver load
- Remove the usage of IopCreateDeviceNode and change it to
  PipAllocateDeviceNode where required
2021-01-04 16:50:32 +03:00
Victor Perevertkin 8ee88d3bd5
[NTOS:PNP] Send removal IRPs to a file system device object for mounted devices
If a DeviceObject has VPB attached, it should be treated in a special way

CORE-16106
2020-12-27 18:40:33 +03:00
Victor Perevertkin 582ca68696
[NTOS:PNP] Improve and refactor PnP notifications
- BUGFIX: do not call IoGetRelatedTargetDevice while guarded mutex is acquired
  (the function issues an APC, but they are disabled inside a critical section)
- BUGFIX: only the beginning of a structure for GUID_PNP_CUSTOM_NOTIFICATION was copied and queued.
  Just pass it as-is to a subscriber, without copying
- Don't convert event GUID to string, store and compare GUID struct itself
- Split IopNotifyPlugPlayNotification into 3 functions for each type of notification
  (less stack usage and for future changes)
- Move initialization code for notifications into a separate routine
- Use separate lists and locks for every type of notification
- Put "TargetDeviceChange" notifications into their place inside DEVICE_NODE
2020-12-05 22:25:40 +03:00
Hermès Bélusca-Maïto 3c722e35b1
[CMD][SERVMAN][SHELL32][WINSPOOL][ROSAPPS][NTOS:PNP] Fix my build. 2020-11-06 01:06:11 +01:00
Victor Perevertkin dc1d717b22
[NTOS:IO] Do not raise an unknown bugcheck inside the PiQueueDeviceAction 2020-08-21 08:50:12 +03:00
Victor Perevertkin acd07e725e
[NTOS:IO] Do device reset inside the PipDeviceActionWorker
This make the operation synchonized with the other device tree actions

CORE-10456 CORE-17150
2020-08-21 08:20:59 +03:00
Victor Perevertkin 2839c85092
[NTOS:IO] Enumerate devices only inside the PipDeviceActionWorker
Introduce the PiPerformSyncDeviceAction routine for queuing
synchronous device actions
Change all kernel code to use PiPerformSyncDeviceAction and
PiQueueDeviceAction for device enumeration

CORE-10456
2020-08-21 08:02:26 +03:00
Victor Perevertkin 2ed132e90e
[NTOS:IO] change DEVICE_ACTION values and rename functions 2020-08-21 07:48:56 +03:00
Victor Perevertkin 21e9e2baa5
[NTOS:IO] Move device manipulation functions from pnpmgr/pnpmgr.c to pnpmgr/devaction.c
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
2020-06-24 04:03:35 +03:00