It’s interesting to hear you say WMI has not been much fun. I’ve had the opposite experience, and frequently make WMI interfaces for drivers, even if it’s just for a test interface during development.
My current tendency is to make a single WMI interface class, with a class name like Company_Product_Interface, that often has minimal data fields like a driver version, and has a bunch of WMI methods to query/set stuff. The reason for this style is it’s easy to make variable size in or out parameters for a method, and much harder for a class. KMDF also has terrible support (like none) for dynamic WMI instances, but it’s easy to have a method that returns a variable size array of WMI objects of a custom WMI class. This kind of interface is not expected to be compatible with any other WMI interface, so is not directly usable by standard tools like perfmon. It’s really optimized for manual use or from a powershell script or C++/C# code.
About two years ago I was doing a high speed fabric driver, and the drivers exposed a huge amount of low level operation/performance data through the WMI interface, things like queue ring pointers, interrupt rates, fragments/sec. I then had a powershell script that created a window with a web browser in it. The powershell code had a timer, and once a second would poll the device performance data through the WMI method interfaces, and write some dynamic html into the web browser, which then did pretty rendering. This was an enormously useful tool for debugging and performance optimization, as when running a test load you could easily see the summary performance metrics that mattered. As a debugging, the early silicon had a errata that sometimes caused a ring to get stuck, and it was instantly apparent on the web page updating every second when you hit this condition. I’ve used this exact kind of thing in the past for customer support debugging, and had a script that could instantly determine if the product was likely operating correctly, and if not what subsystem had a problem. This support WMI interface could dump all the device registers in a format that was useful for technical support engineers.
About 5 years ago, I worked on a communication protocol driver, and it used a WMI interface for exercising all the little corners of the protocol. There was a powershell script that made WMI calls to initiate connections, set parameters, and do data transfers. The WMI interface was actually to a test driver that called the protocol driver, and was written concurrently with the protocol driver. I used the test driver during development to exercise all kinds of paths, and inject error conditions, and collect operational data. The test driver was designed like this so it could test an interface API, which was then used by other components in the product. There was going to be multiple implementations of the protocol driver, one in pure software using kernel sockets, and one that used an interface much more tied to the hardware.
My biggest complaint about WMI is the WDK driver creation wizard does not automatically generate WMI code. I find I almost always have a WMI interface in drivers, and have to manually add essentially boilerplate code every time I do a new driver. Some of the docs on WMI are a bit lacking too
Some things I really like about WMI include:
- The data has rich metadata, so calling from a dynamic script language is really easy
- Performance is “good enough” for lots of uses, in the range of 1000 method calls/sec
- WMI data is accessible remotely, so my desktop can read WMI data from any remote machine
- Once you add the initialization boilerplate code, adding a new method is easy
- There is a single consistent access method for kernel or user WMI providers
- Linux folks can understand when you tell them WMI is like a /sys interface
Jan
-----Original Message-----
From: xxxxx@lists.osr.com On Behalf Of xxxxx@osr.com
Sent: Thursday, July 5, 2018 8:46 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Exposing sensors (current, voltage, temperature) in a device
Agreed. The sensor-class stuff isn’t what you’re looking for, unless you want to have Windows use it as input to control the fan speed or something.
Correct. I mean… what COULD there be, right? Your temperature sensor could be hooked-up to ANYthing. I don’t think there’s a built-in app that says “You wine cellar temperature is 60 degrees”… or “Your PCB etch bath temp is 105 degrees… have a nice day”
So, before I wave to you as you go down that long and painful path, I’ve just GOT to ask: Do you really think folks will care about using these interfaces to talk to your sensors?
I get that you can make the argument: Well, you can invoke WMI interfaces from just-about anywhere… C#, PowerShell, and what not. And you can’t do that with IOCTLs. Is that enough value for you to go through the effort?
I guess what I’m asking is… have your Product Management people done their due diligence and determined this is a good idea? Cuz my experience with WMI is that it’s not much fun.
Peter
OSR
@OSRDrivers
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>