[NTOS:PNP] IopEnumerateDetectedDevices(): General refactoring

[HBelusca]

**NOTE: Made on behalf of @binarymaster **

Purpose

• Deduplicate a while-loop by adding one more recursive call.
• Add IopMapDetectedDeviceId() helper function with a structure in order to reduce hardcoded constants and checks.

JIRA issue: CORE-18962

[Extravert-ir]

This stuff should be moved to HAL, the kernel must not be responsible for mapping devices on a particular type of system.
Also, the way it is done is very hacky - one must not write resources directly to HKLM/System/CCS/Enum, devices should be exposed as PDOs on HAL bus.

That would be a refactoring!

[HBelusca]

the kernel must not be responsible for mapping devices on a particular type of system

Is this because the kernel should stay as much as possible system-agnostic, while the HAL indeed can depend on the system it supports?

[HBelusca]

Reply from @binarymaster :

This stuff should be moved to HAL, the kernel must not be responsible for mapping devices on a particular type of system.

I can agree with this, specifically for the controllers that may have different PnP identifiers on different types of systems (e.g. PC/AT vs. PC-98), however some known devices would always have the same identifiers (most keyboards and mices). Redesigning it the way you described is a good idea, but it's out of scope of this PR.

Also, the way it is done is very hacky - one must not write resources directly to HKLM/System/CCS/Enum, devices should be exposed as PDOs on HAL bus.

This is correct, however the goal of this PR/patch is to simplify the function, reducing amount of code, without breaking current logic in any way (even if it's not perfect). Changing the things in a more correct way that you described would rather be a "bugfix"/"enhancement" than refactoring. 🙂

[disean]

This stuff should be moved to HAL

Why not leave this device mapping logic in the kernel for compatibility?

[Extravert-ir]

Is this because the kernel should stay as much as possible system-agnostic, while the HAL indeed can depend on the system it supports?

There is a general code in the kernel for managing device objects and its resources, and it is PnP device management code. This "firmware mapper" thing creates a parallel code path which does the same thing. I want to remove it to avoid code duplication and bugs.

Why not leave this device mapping logic in the kernel for compatibility?

For compatibility with what?

[disean]

For compatibility with what?

Example: replacing the hal.dll with one from Windows

[Extravert-ir]

replacing the hal.dll with one from Windows

Such scenario will not be supported by ReactOS. Supporting HALs from Windows (2003) is a quite an amount of work, and puts too many restrictions on internal design of things