Page Comparison

...

Note: Please note that this is draft, we may want to split drivers in a different way e.g. core PMU and uncore PMU as two separate drivers (not three like its stated below). See below draft of ideas and possible solutions to DT architecture. Further chapters should describe architecture we want o actually implement.

• [ON HOLD] Split current wperf-driver into three separate independent drivers (core, DSU and DMC driver).

• Introduce “driver type” for WindowsPerf drivers in DT.

  • “core PMU” driver type to support vanilla Arm PMUs.

  • “uncore PMU” driver(s):

    • Introduce “DSU” driver type to support uncore PMU counting.

    • Introduce “DMC” driver type to support Dynamic Memory Controllers.

• [ON HOLD] Introduce driver “template” for each type.

  • Note: We may want to have one template for “PMU like devices”

• [ON HOLD] Move current wperf-driver core PMU and uncore PMU implementations under new driver types.

• Add DT driver enumeration to user space.

  • Adapt wperf and drivers to communicate with N drivers installed.

  • Adapt wperf-devgen to support new driver types enumeration and installation / removal.

...

• https://gitlab.com/Linaro/WindowsPerf/windowsperf/-/tree/feature-WPERF-729?ref_type=heads

  • based on work for

    Jira Legacy
    server System Jira serverId 59107c6f-1e52-32bc-b58f-400d54bba998 key WPERF-729

    .

• Comments from Matthew Sykes (Deactivated) I got from Slack (just to archive here):

  • This is the IOCTL handler. The concept of 'queue' is a bit old fashioned to be honest, I dont know why MSFT used it in KMDF, but they have, and the 'queue init' code sets the IOCTL handler entry point.

  • Device create sets the File Open and CLose entry point, so those handlers are in device.c
    WDM drivers are much cleaner in this respect, open, close, ioctl, are just Irp requests, and all set in the same place and often handled in the same file

  • Then you have power and plug and play handlers, they also have their own files
    IOCTL handlers by their nature can be huge

  • Especially so since often the Irp needs handling on the way back up from a lower device, to there is twice as much code, one section sends it down, the other handles it on the way up, as the lower driver, usually a PDO, sets some values in the Irp

  • But yeah, its a bit of a moot point whether to put queue and ioctl into two files or one, as they are actually the same thing in KMDF

    • Image Added

  • Linaro Dummy is the driver, and the yellow bang is saying:

    • Image Added

  • "The device cannot find enough free resources" , yet clearly in the previous screen shot there is nothing else using this range. So its almost as if  the system has reserved it and wont let the DMC have it.

Kernel - user-space Interface

...