Re: WMI and Kernel:User interface

[Pali RohÃr]

Hi Greg! I will try to explain that problem with calling WMI functions.

On Tuesday 13 June 2017 18:57:14 Greg KH wrote:
> > Getting there requires work in a few areas:
> > 1) The OEM/IBV exports the methods and the MOF (in binary form)
> > that describes the objects that can be interacted with and what
> > kind of data needs to be sent.
> 
> What do you mean by this?

In ACPI is stored buffer with binary MOF data. Those data contains 
description WMI object system where are classes with methods and 
attributes (similar to C++). Then there are stored mapping from 
particular class method/attribute to WMI id.

If you want to call WMI method (which is basically ACPI method), you 
need to know WMI id and call specific ACPI method with that id and other 
magic.

Taking those magic values is not easy and WMI kernel drivers just 
reverse engineered them from ACPI bytecode or other method.

But correct way is to parse that binary MOF data and build mapping from 
classes, methods and attributes to WMI ids (needed for raw ACPI call).

Problem is that format of those binary MOF data is unknown (generated by 
program mofcomp.exe available in all MS Windows systems), but finally I 
was able to guess its structure and write "decompiler".

Search for email with subject "Binary MOF buffer in WMI is finally 
decoded!" for more details which I sent week ago to LKML.

> > 2) Kernel needs to provide a way to userspace to get to this data
> 
> Why, what can userspace do with this?

Userspace want to call WMI method "Method1" from WMI class "Class1" from 
namespace "Namespace1". And wants to know signature of that Method1, 
what are input arguments, what are outputs...

Those MOF data contains descriptions of arguments and also information 
which ACPI method with which WMI id needs to be called to execute above 
"Method1".

-- 
Pali RohÃr
pali.rohar@xxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part.