On Sat, May 27, 2017 at 01:14:15PM +0200, Pali Roh?r wrote:
> Hi! Note that in WMI is stored binary MOF (BMOF; .bmf file; compiled
> MOF), not ordinary MOF data which are plain text. So maybe it could make
> sense to include "B" into name of sysfs entry? Or not? (Just suggestion)
Did some digging, and .... yeah, you're right.
I've replaced with MOF with Binary MOF or bmof throughout the patch. Will resend
in a v2. Thanks.
>
> On Saturday 27 May 2017 07:31:29 Darren Hart wrote:
> > From: Andy Lutomirski <[email protected]>
> >
> > Quite a few laptops (and maybe servers?) have embedded WMI MOF
>
> Not "a few", but "lots of" :-)
I'll just use "Many" and save us continued debate :-)
>
> > metadata. I think that Samba has tools to interpret it, but there is
> > currently no interface to get the data in the first place.
>
> No, there is no non-ms-windows tool for interpreting those binary MOF
> (BMF) data yet.
Good point. Updated.
>
> > + priv->mofdata = wmidev_block_query(wdev, 0);
> > + if (!priv->mofdata) {
> > + dev_warn(&wdev->dev, "failed to read MOF\n");
> > + return -EIO;
> > + }
> > +
> > + if (priv->mofdata->type != ACPI_TYPE_BUFFER) {
> > + dev_warn(&wdev->dev, "MOF is not a buffer\n");
> > + ret = -EIO;
> > + goto err_free;
> > + }
>
> Are not those problems fatal for driver and therefore dev_err() better?
>
Yes, agreed. Updated.
> > + sysfs_bin_attr_init(&priv->mof_bin_attr);
> > + priv->mof_bin_attr.attr.name = "mof";
> > + priv->mof_bin_attr.attr.mode = 0400;
>
> 0400 means to be readable only by root? Is there then reason why normal
> user should not be able to read it?
>
We can always open access up, harder to lock it down later. Let's start with
this and adjust if necessary.
--
Darren Hart
VMware Open Source Technology Center
On Tuesday 06 June 2017 00:14:56 Darren Hart wrote:
> On Sat, May 27, 2017 at 01:14:15PM +0200, Pali Rohár wrote:
> > > metadata. I think that Samba has tools to interpret it, but there
> > > is currently no interface to get the data in the first place.
> >
> > No, there is no non-ms-windows tool for interpreting those binary
> > MOF (BMF) data yet.
>
> Good point. Updated.
You are too late :-) Now there is my at https://github.com/pali/bmfdec
See my email "Binary MOF buffer in WMI is finally decoded!".
--
Pali Rohár
[email protected]
On Mon, Jun 5, 2017 at 3:19 PM, Pali Rohár <[email protected]> wrote:
> On Tuesday 06 June 2017 00:14:56 Darren Hart wrote:
>> On Sat, May 27, 2017 at 01:14:15PM +0200, Pali Rohár wrote:
>> > > metadata. I think that Samba has tools to interpret it, but there
>> > > is currently no interface to get the data in the first place.
>> >
>> > No, there is no non-ms-windows tool for interpreting those binary
>> > MOF (BMF) data yet.
>>
>> Good point. Updated.
>
> You are too late :-) Now there is my at https://github.com/pali/bmfdec
> See my email "Binary MOF buffer in WMI is finally decoded!".
>
It comes out like this on my laptop. I don't know enough about MOF to
know what we're supposed to do with this, but I suspect it at least
gives us the sizes of buffers that we should be passing to the various
methods.
class WMIEvent : __ExtrinsicEvent {
};
[WMI, Locale("MS\0x409"), Description("QDATA"),
guid("{ABBC0F60-8EA1-11d1-00A0-C90629100000}")]
class QDat {
[WmiDataId(1), read, write, Description("qdata")] uint8 Bytes[128];
};
[WMI, Dynamic, Provider("WmiProv"), Locale("MS\0x409"),
Description("BIOS WMI Query"),
guid("{8D9DDCBC-A997-11DA-B012-B622A1EF5492}")]
class WMI_Query {
[key, read] String InstanceName;
[read] Boolean Active;
[WmiDataId(1), read, write, Description("BIOS WMI info")] QDat QDATA;
};
[WMI, Locale("MS\0x409"), Description("Data"),
guid("{a3776ce0-1e88-11db-a98b-0800200c9a66}")]
class BDat {
[WmiDataId(1), read, write, Description("data")] uint8 Bytes[4096];
};
[WMI, Dynamic, Provider("WmiProv"), Locale("MS\0x409"),
Description("Interface"),
guid("{A80593CE-A997-11DA-B012-B622A1EF5492}")]
class BFn {
[key, read] String InstanceName;
[read] Boolean Active;
[WmiMethodId(1), Implemented, read, write, Description("Do BFn")]
void DoBFn([in, Description("Fn buf"), ID(0)] BDat Data, [out,
Description("Fn buf"), ID(0)] BDat Data);
};
[WMI, Dynamic, Provider("WmiProv"), Locale("MS\0x409"),
Description("Event"), guid("{9DBB5994-A997-11DA-B012-B622A1EF5492}")]
class BIOSEvent : WmiEvent {
[key, read] String InstanceName;
[read] Boolean Active;
[WmiDataId(1), read, write, Description("Ev buf")] QDat Data;
};
On Tue, Jun 06, 2017 at 12:19:26AM +0200, Pali Roh?r wrote:
> On Tuesday 06 June 2017 00:14:56 Darren Hart wrote:
> > On Sat, May 27, 2017 at 01:14:15PM +0200, Pali Roh?r wrote:
> > > > metadata. I think that Samba has tools to interpret it, but there
> > > > is currently no interface to get the data in the first place.
> > >
> > > No, there is no non-ms-windows tool for interpreting those binary
> > > MOF (BMF) data yet.
> >
> > Good point. Updated.
>
> You are too late :-) Now there is my at https://github.com/pali/bmfdec
> See my email "Binary MOF buffer in WMI is finally decoded!".
I've seen it, nice work. Will spend more time on it once I get the v2 for this
out the door.
--
Darren Hart
VMware Open Source Technology Center
On Monday 05 June 2017 15:39:44 Andy Lutomirski wrote:
> On Mon, Jun 5, 2017 at 3:19 PM, Pali Rohár <[email protected]> wrote:
> > On Tuesday 06 June 2017 00:14:56 Darren Hart wrote:
> >> On Sat, May 27, 2017 at 01:14:15PM +0200, Pali Rohár wrote:
> >> > > metadata. I think that Samba has tools to interpret it, but there
> >> > > is currently no interface to get the data in the first place.
> >> >
> >> > No, there is no non-ms-windows tool for interpreting those binary
> >> > MOF (BMF) data yet.
> >>
> >> Good point. Updated.
> >
> > You are too late :-) Now there is my at https://github.com/pali/bmfdec
> > See my email "Binary MOF buffer in WMI is finally decoded!".
> >
>
> It comes out like this on my laptop. I don't know enough about MOF to
> know what we're supposed to do with this, but I suspect it at least
> gives us the sizes of buffers that we should be passing to the various
> methods.
There are two tools bmfparse and bmf2mof. Difference is just output
format.
Important are WmiDataId and WmiMethodId qualifiers. Those define ids are
what are passed to kernel function wmi_evaluate_method(). Ids are
processed by corresponding WMxx ACPI function.
So instead of
wmi_evaluate_method(guid, instance, method_id, acpi_in, acpi_out);
it should be possible to call:
wmi_evaluate_method_name(class, name, input_params, output_params);
(once somebody implement wmi_evaluate_method_name function)
It is more readable in code to use class and function names instead of
some guids and random meaningless numbers. Also it would allow to check
size of input buffer (or types).
E.g.
BDat data_in;
BDat data_out;
// fill data_in.Bytes
wmi_evaluate_method_name("BFn", "DoBFn", &data_in, &data_out);
// output is in data_out.Bytes
could be translated to:
wmi_evaluate_method("A80593CE-A997-11DA-B012-B622A1EF5492", 0, 1, acpi_in, acpi_out);
Sometimes method_id is random number and hard to guess it. One of
possible solution is to trace ACPI calls on Windows, another is decode
that BMOF buffer and take correct method_id.
I will probably write another one tool which prints just important WMI
functions and their mapping to WMI ids + input/output parameters.
Without all other MOF data which are not relevant to ACPI-WMI.
> class WMIEvent : __ExtrinsicEvent {
> };
>
> [WMI, Locale("MS\0x409"), Description("QDATA"),
> guid("{ABBC0F60-8EA1-11d1-00A0-C90629100000}")]
> class QDat {
> [WmiDataId(1), read, write, Description("qdata")] uint8 Bytes[128];
> };
>
> [WMI, Dynamic, Provider("WmiProv"), Locale("MS\0x409"),
> Description("BIOS WMI Query"),
> guid("{8D9DDCBC-A997-11DA-B012-B622A1EF5492}")]
> class WMI_Query {
> [key, read] String InstanceName;
> [read] Boolean Active;
> [WmiDataId(1), read, write, Description("BIOS WMI info")] QDat QDATA;
> };
>
> [WMI, Locale("MS\0x409"), Description("Data"),
> guid("{a3776ce0-1e88-11db-a98b-0800200c9a66}")]
> class BDat {
> [WmiDataId(1), read, write, Description("data")] uint8 Bytes[4096];
> };
>
> [WMI, Dynamic, Provider("WmiProv"), Locale("MS\0x409"),
> Description("Interface"),
> guid("{A80593CE-A997-11DA-B012-B622A1EF5492}")]
> class BFn {
> [key, read] String InstanceName;
> [read] Boolean Active;
>
> [WmiMethodId(1), Implemented, read, write, Description("Do BFn")]
> void DoBFn([in, Description("Fn buf"), ID(0)] BDat Data, [out,
> Description("Fn buf"), ID(0)] BDat Data);
> };
>
> [WMI, Dynamic, Provider("WmiProv"), Locale("MS\0x409"),
> Description("Event"), guid("{9DBB5994-A997-11DA-B012-B622A1EF5492}")]
> class BIOSEvent : WmiEvent {
> [key, read] String InstanceName;
> [read] Boolean Active;
> [WmiDataId(1), read, write, Description("Ev buf")] QDat Data;
> };
--
Pali Rohár
[email protected]
Pali,
Amazing job with what you've done so far. A few comments I wanted to share from my taking look at your bmf2mof and comparing to "source" MOF.
1) At least in source the case used for String and Boolean is lower case. I'm unsure if that actually matters for any MOF parsing tools, but I wanted to FYI in case it does.
2) On my system when you expand the arguments for "void DoBFn" the source doesn't describe individual arguments like you do.
Again this might not matter to MOF parsing tools but wanted to let you know in case it does.
source:
void DoBFn([in, out, Description("Fn buf")] BDat Data);
bmf2mof:
void doBFn([in, Description("Fn buf"), ID(0)] BDat Data, [out, Description("Fn buf"), ID(0)] BDat Data);
> -----Original Message-----
> From: Pali Rohár [mailto:[email protected]]
> Sent: Tuesday, June 6, 2017 6:06 AM
> To: Andy Lutomirski <[email protected]>
> Cc: Darren Hart <[email protected]>; [email protected];
> Andy Shevchenko <[email protected]>; Andy Lutomirski
> <[email protected]>; Limonciello, Mario <[email protected]>; Rafael
> Wysocki <[email protected]>; [email protected]; Linux ACPI <linux-
> [email protected]>
> Subject: Re: [PATCH 15/16] platform/x86: wmi-mof: New driver to expose
> embedded WMI MOF metadata
>
> On Monday 05 June 2017 15:39:44 Andy Lutomirski wrote:
> > On Mon, Jun 5, 2017 at 3:19 PM, Pali Rohár <[email protected]> wrote:
> > > On Tuesday 06 June 2017 00:14:56 Darren Hart wrote:
> > >> On Sat, May 27, 2017 at 01:14:15PM +0200, Pali Rohár wrote:
> > >> > > metadata. I think that Samba has tools to interpret it, but there
> > >> > > is currently no interface to get the data in the first place.
> > >> >
> > >> > No, there is no non-ms-windows tool for interpreting those binary
> > >> > MOF (BMF) data yet.
> > >>
> > >> Good point. Updated.
> > >
> > > You are too late :-) Now there is my at https://github.com/pali/bmfdec
> > > See my email "Binary MOF buffer in WMI is finally decoded!".
> > >
> >
> > It comes out like this on my laptop. I don't know enough about MOF to
> > know what we're supposed to do with this, but I suspect it at least
> > gives us the sizes of buffers that we should be passing to the various
> > methods.
>
Yes, the size of the buffers and the format of the data you can pass in them is
what is most important bit of information that comes out of this.
> There are two tools bmfparse and bmf2mof. Difference is just output
> format.
>
> Important are WmiDataId and WmiMethodId qualifiers. Those define ids are
> what are passed to kernel function wmi_evaluate_method(). Ids are
> processed by corresponding WMxx ACPI function.
>
> So instead of
>
> wmi_evaluate_method(guid, instance, method_id, acpi_in, acpi_out);
>
> it should be possible to call:
>
> wmi_evaluate_method_name(class, name, input_params, output_params);
>
> (once somebody implement wmi_evaluate_method_name function)
>
Now that you have managed to decode binary MOF, it might actually change
what makes sense to export to userspace. We were previously
discussing exporting GUID's (eg something like /dev/wmi-$GUID)
but with readable names that actually map to the GUID's, it makes more sense
to export the classes. Userspace tools can parse the exported MOF to know
how to interact with those classes, and the classes can then map to chardevices.
For example on a Dell system today /dev/wmi-BFn would be the most important
to export (this will change in the future).
> It is more readable in code to use class and function names instead of
> some guids and random meaningless numbers. Also it would allow to check
> size of input buffer (or types).
Completely agree. Once the parser can be brought into kernel, this is a very
good next change for existing WMI drivers.
>
> E.g.
>
> BDat data_in;
> BDat data_out;
> // fill data_in.Bytes
> wmi_evaluate_method_name("BFn", "DoBFn", &data_in, &data_out);
> // output is in data_out.Bytes
>
> could be translated to:
>
> wmi_evaluate_method("A80593CE-A997-11DA-B012-B622A1EF5492", 0, 1,
> acpi_in, acpi_out);
>
> Sometimes method_id is random number and hard to guess it. One of
> possible solution is to trace ACPI calls on Windows, another is decode
> that BMOF buffer and take correct method_id.
>
> I will probably write another one tool which prints just important WMI
> functions and their mapping to WMI ids + input/output parameters.
> Without all other MOF data which are not relevant to ACPI-WMI.
When this goes into the kernel, I think it would be ideal to export MOF
exactly like your bmf2mof does.
The userspace MOF parsing tools that already exist will be able to process
it more effectively this way.
Perhaps internally in the kernel this mapping information will be useful to
be able to create wmi_evaluate_method_name.
>
> > class WMIEvent : __ExtrinsicEvent {
> > };
> >
> > [WMI, Locale("MS\0x409"), Description("QDATA"),
> > guid("{ABBC0F60-8EA1-11d1-00A0-C90629100000}")]
> > class QDat {
> > [WmiDataId(1), read, write, Description("qdata")] uint8 Bytes[128];
> > };
> >
> > [WMI, Dynamic, Provider("WmiProv"), Locale("MS\0x409"),
> > Description("BIOS WMI Query"),
> > guid("{8D9DDCBC-A997-11DA-B012-B622A1EF5492}")]
> > class WMI_Query {
> > [key, read] String InstanceName;
> > [read] Boolean Active;
> > [WmiDataId(1), read, write, Description("BIOS WMI info")] QDat QDATA;
> > };
> >
> > [WMI, Locale("MS\0x409"), Description("Data"),
> > guid("{a3776ce0-1e88-11db-a98b-0800200c9a66}")]
> > class BDat {
> > [WmiDataId(1), read, write, Description("data")] uint8 Bytes[4096];
> > };
> >
> > [WMI, Dynamic, Provider("WmiProv"), Locale("MS\0x409"),
> > Description("Interface"),
> > guid("{A80593CE-A997-11DA-B012-B622A1EF5492}")]
> > class BFn {
> > [key, read] String InstanceName;
> > [read] Boolean Active;
> >
> > [WmiMethodId(1), Implemented, read, write, Description("Do BFn")]
> > void DoBFn([in, Description("Fn buf"), ID(0)] BDat Data, [out,
> > Description("Fn buf"), ID(0)] BDat Data);
> > };
> >
> > [WMI, Dynamic, Provider("WmiProv"), Locale("MS\0x409"),
> > Description("Event"), guid("{9DBB5994-A997-11DA-B012-B622A1EF5492}")]
> > class BIOSEvent : WmiEvent {
> > [key, read] String InstanceName;
> > [read] Boolean Active;
> > [WmiDataId(1), read, write, Description("Ev buf")] QDat Data;
> > };
>
> --
> Pali Rohár
> [email protected]
On Tuesday 06 June 2017 13:46:16 [email protected] wrote:
> Pali,
>
> Amazing job with what you've done so far. A few comments I wanted to share from my taking look at your bmf2mof and comparing to "source" MOF.
> 1) At least in source the case used for String and Boolean is lower case. I'm unsure if that actually matters for any MOF parsing tools, but I wanted to FYI in case it does.
In MS documentation is String, Boolean and Datetime with first char
uppercase. But looks like mofcomp accept both upper case and lower case
variants.
> 2) On my system when you expand the arguments for "void DoBFn" the source doesn't describe individual arguments like you do.
> Again this might not matter to MOF parsing tools but wanted to let you know in case it does.
I know, this part is missing. Order of arguments are only in ID
qualifier and not sorted + in/out de-duplicated.
> source:
> void DoBFn([in, out, Description("Fn buf")] BDat Data);
> bmf2mof:
> void doBFn([in, Description("Fn buf"), ID(0)] BDat Data, [out, Description("Fn buf"), ID(0)] BDat Data);
--
Pali Rohár
[email protected]
On Tuesday 06 June 2017 15:56:21 Pali Rohár wrote:
> On Tuesday 06 June 2017 13:46:16 [email protected] wrote:
> > 2) On my system when you expand the arguments for "void DoBFn" the
> > source doesn't describe individual arguments like you do. Again
> > this might not matter to MOF parsing tools but wanted to let you
> > know in case it does.
>
> I know, this part is missing. Order of arguments are only in ID
> qualifier and not sorted + in/out de-duplicated.
Implemented! Now arguments are correctly placed based on ID qualifier.
> > source:
> > void DoBFn([in, out, Description("Fn buf")] BDat Data);
> >
> > bmf2mof:
> > void doBFn([in, Description("Fn buf"), ID(0)] BDat Data, [out,
> > Description("Fn buf"), ID(0)] BDat Data);
--
Pali Rohár
[email protected]
> -----Original Message-----
> From: Pali Rohár [mailto:[email protected]]
> Sent: Wednesday, June 7, 2017 12:39 PM
> To: Limonciello, Mario <[email protected]>
> Cc: [email protected]; [email protected]; platform-driver-
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]
> Subject: Re: [PATCH 15/16] platform/x86: wmi-mof: New driver to expose
> embedded WMI MOF metadata
>
> On Tuesday 06 June 2017 15:56:21 Pali Rohár wrote:
> > On Tuesday 06 June 2017 13:46:16 [email protected] wrote:
> > > 2) On my system when you expand the arguments for "void DoBFn" the
> > > source doesn't describe individual arguments like you do. Again
> > > this might not matter to MOF parsing tools but wanted to let you
> > > know in case it does.
> >
> > I know, this part is missing. Order of arguments are only in ID
> > qualifier and not sorted + in/out de-duplicated.
>
> Implemented! Now arguments are correctly placed based on ID qualifier.
I think it's still off a little though.
What I'm getting back now from bmf2mof is:
void DoBFn([in, Description("Fn buf"), out] BDat Data);
Whereas source puts Description as the last argument:
void DoBFn([in, out, Description("Fn buf")] BDat Data);
>
> > > source:
> > > void DoBFn([in, out, Description("Fn buf")] BDat Data);
> > >
> > > bmf2mof:
> > > void doBFn([in, Description("Fn buf"), ID(0)] BDat Data, [out,
> > > Description("Fn buf"), ID(0)] BDat Data);
>
> --
> Pali Rohár
> [email protected]
On Wednesday 07 June 2017 22:23:08 [email protected] wrote:
> > -----Original Message-----
> > From: Pali Rohár [mailto:[email protected]]
> > Sent: Wednesday, June 7, 2017 12:39 PM
> > To: Limonciello, Mario <[email protected]>
> > Cc: [email protected]; [email protected]; platform-driver-
> > [email protected]; [email protected];
> > [email protected]; [email protected]; [email protected];
> > [email protected] Subject: Re: [PATCH 15/16]
> > platform/x86: wmi-mof: New driver to expose embedded WMI MOF
> > metadata
> >
> > On Tuesday 06 June 2017 15:56:21 Pali Rohár wrote:
> > > On Tuesday 06 June 2017 13:46:16 [email protected] wrote:
> > > > 2) On my system when you expand the arguments for "void DoBFn"
> > > > the source doesn't describe individual arguments like you do.
> > > > Again this might not matter to MOF parsing tools but wanted to
> > > > let you know in case it does.
> > >
> > > I know, this part is missing. Order of arguments are only in ID
> > > qualifier and not sorted + in/out de-duplicated.
> >
> > Implemented! Now arguments are correctly placed based on ID
> > qualifier.
>
> I think it's still off a little though.
>
> What I'm getting back now from bmf2mof is:
> void DoBFn([in, Description("Fn buf"), out] BDat Data);
>
> Whereas source puts Description as the last argument:
> void DoBFn([in, out, Description("Fn buf")] BDat Data);
In BMOF from my Latitude E6440 there are specified two parameters with
index 0. One with qualifiers ("in", Description("Fn buf")) and one with
("out", Description("Fn buf")). I think you have similar/same data in
BMOF.
In my bmf2mof I just combined those two parameters into one (when name,
type and index matches) and concatenate also qualifiers with removing
duplicates.
Do not know what is correct way, but I think qualifiers are just
unordered set. MS decompiler probably put "in" and "out" qualifiers
before any other for better readability.
> > > > source:
> > > > void DoBFn([in, out, Description("Fn buf")] BDat Data);
> > > >
> > > > bmf2mof:
> > > > void doBFn([in, Description("Fn buf"), ID(0)] BDat Data, [out,
> > > > Description("Fn buf"), ID(0)] BDat Data);
> >
> > --
> > Pali Rohár
> > [email protected]
--
Pali Rohár
[email protected]
> -----Original Message-----
> From: Pali Rohár [mailto:[email protected]]
> Sent: Wednesday, June 7, 2017 3:50 PM
> To: Limonciello, Mario <[email protected]>
> Cc: [email protected]; [email protected]; platform-driver-
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]
> Subject: Re: [PATCH 15/16] platform/x86: wmi-mof: New driver to expose
> embedded WMI MOF metadata
>
> On Wednesday 07 June 2017 22:23:08 [email protected] wrote:
> > > -----Original Message-----
> > > From: Pali Rohár [mailto:[email protected]]
> > > Sent: Wednesday, June 7, 2017 12:39 PM
> > > To: Limonciello, Mario <[email protected]>
> > > Cc: [email protected]; [email protected]; platform-driver-
> > > [email protected]; [email protected];
> > > [email protected]; [email protected]; [email protected];
> > > [email protected] Subject: Re: [PATCH 15/16]
> > > platform/x86: wmi-mof: New driver to expose embedded WMI MOF
> > > metadata
> > >
> > > On Tuesday 06 June 2017 15:56:21 Pali Rohár wrote:
> > > > On Tuesday 06 June 2017 13:46:16 [email protected] wrote:
> > > > > 2) On my system when you expand the arguments for "void DoBFn"
> > > > > the source doesn't describe individual arguments like you do.
> > > > > Again this might not matter to MOF parsing tools but wanted to
> > > > > let you know in case it does.
> > > >
> > > > I know, this part is missing. Order of arguments are only in ID
> > > > qualifier and not sorted + in/out de-duplicated.
> > >
> > > Implemented! Now arguments are correctly placed based on ID
> > > qualifier.
> >
> > I think it's still off a little though.
> >
> > What I'm getting back now from bmf2mof is:
> > void DoBFn([in, Description("Fn buf"), out] BDat Data);
> >
> > Whereas source puts Description as the last argument:
> > void DoBFn([in, out, Description("Fn buf")] BDat Data);
>
> In BMOF from my Latitude E6440 there are specified two parameters with
> index 0. One with qualifiers ("in", Description("Fn buf")) and one with
> ("out", Description("Fn buf")). I think you have similar/same data in
> BMOF.
>
> In my bmf2mof I just combined those two parameters into one (when name,
> type and index matches) and concatenate also qualifiers with removing
> duplicates.
>
> Do not know what is correct way, but I think qualifiers are just
> unordered set. MS decompiler probably put "in" and "out" qualifiers
> before any other for better readability.
Have you tried to run it through mofcomp.exe and then decompile again
with bmf2mof? As long as it's coming out the same you're probably right.
>
> > > > > source:
> > > > > void DoBFn([in, out, Description("Fn buf")] BDat Data);
> > > > >
> > > > > bmf2mof:
> > > > > void doBFn([in, Description("Fn buf"), ID(0)] BDat Data, [out,
> > > > > Description("Fn buf"), ID(0)] BDat Data);
> > >
> > > --
> > > Pali Rohár
> > > [email protected]
>
> --
> Pali Rohár
> [email protected]
On Friday 09 June 2017 17:46:12 [email protected] wrote:
> > -----Original Message-----
> > From: Pali Rohár [mailto:[email protected]]
> > Sent: Wednesday, June 7, 2017 3:50 PM
> > To: Limonciello, Mario <[email protected]>
> > Cc: [email protected]; [email protected]; platform-driver-
> > [email protected]; [email protected];
> > [email protected]; [email protected]; [email protected];
> > [email protected] Subject: Re: [PATCH 15/16]
> > platform/x86: wmi-mof: New driver to expose embedded WMI MOF
> > metadata
> >
> > On Wednesday 07 June 2017 22:23:08 [email protected] wrote:
> > > > -----Original Message-----
> > > > From: Pali Rohár [mailto:[email protected]]
> > > > Sent: Wednesday, June 7, 2017 12:39 PM
> > > > To: Limonciello, Mario <[email protected]>
> > > > Cc: [email protected]; [email protected]; platform-driver-
> > > > [email protected]; [email protected];
> > > > [email protected]; [email protected];
> > > > [email protected]; [email protected]
> > > > Subject: Re: [PATCH 15/16]
> > > > platform/x86: wmi-mof: New driver to expose embedded WMI MOF
> > > > metadata
> > > >
> > > > On Tuesday 06 June 2017 15:56:21 Pali Rohár wrote:
> > > > > On Tuesday 06 June 2017 13:46:16 [email protected]
> > > > > wrote:
> > > > > > 2) On my system when you expand the arguments for "void
> > > > > > DoBFn" the source doesn't describe individual arguments
> > > > > > like you do. Again this might not matter to MOF parsing
> > > > > > tools but wanted to let you know in case it does.
> > > > >
> > > > > I know, this part is missing. Order of arguments are only in
> > > > > ID qualifier and not sorted + in/out de-duplicated.
> > > >
> > > > Implemented! Now arguments are correctly placed based on ID
> > > > qualifier.
> > >
> > > I think it's still off a little though.
> > >
> > > What I'm getting back now from bmf2mof is:
> > > void DoBFn([in, Description("Fn buf"), out] BDat Data);
> > >
> > > Whereas source puts Description as the last argument:
> > > void DoBFn([in, out, Description("Fn buf")] BDat Data);
> >
> > In BMOF from my Latitude E6440 there are specified two parameters
> > with index 0. One with qualifiers ("in", Description("Fn buf"))
> > and one with ("out", Description("Fn buf")). I think you have
> > similar/same data in BMOF.
> >
> > In my bmf2mof I just combined those two parameters into one (when
> > name, type and index matches) and concatenate also qualifiers with
> > removing duplicates.
> >
> > Do not know what is correct way, but I think qualifiers are just
> > unordered set. MS decompiler probably put "in" and "out" qualifiers
> > before any other for better readability.
>
> Have you tried to run it through mofcomp.exe and then decompile again
> with bmf2mof? As long as it's coming out the same you're probably
> right.
Yes, bmf2mof+mofcomp.exe+bmf2mof gives same output as just bmf2mof.
> > > > > > source:
> > > > > > void DoBFn([in, out, Description("Fn buf")] BDat Data);
> > > > > >
> > > > > > bmf2mof:
> > > > > > void doBFn([in, Description("Fn buf"), ID(0)] BDat Data,
> > > > > > [out, Description("Fn buf"), ID(0)] BDat Data);
> > > >
> > > > --
> > > > Pali Rohár
> > > > [email protected]
> >
> > --
> > Pali Rohár
> > [email protected]
--
Pali Rohár
[email protected]
On Friday 09 June 2017 23:51:32 Pali Rohár wrote:
> On Friday 09 June 2017 17:46:12 [email protected] wrote:
> > > -----Original Message-----
> > > From: Pali Rohár [mailto:[email protected]]
> > > Sent: Wednesday, June 7, 2017 3:50 PM
> > > To: Limonciello, Mario <[email protected]>
> > > Cc: [email protected]; [email protected]; platform-driver-
> > > [email protected]; [email protected];
> > > [email protected]; [email protected]; [email protected];
> > > [email protected] Subject: Re: [PATCH 15/16]
> > > platform/x86: wmi-mof: New driver to expose embedded WMI MOF
> > > metadata
> > >
> > > On Wednesday 07 June 2017 22:23:08 [email protected]
> > > wrote:
> > > > > -----Original Message-----
> > > > > From: Pali Rohár [mailto:[email protected]]
> > > > > Sent: Wednesday, June 7, 2017 12:39 PM
> > > > > To: Limonciello, Mario <[email protected]>
> > > > > Cc: [email protected]; [email protected];
> > > > > platform-driver- [email protected];
> > > > > [email protected]; [email protected];
> > > > > [email protected];
> > > > > [email protected]; [email protected]
> > > > > Subject: Re: [PATCH 15/16]
> > > > > platform/x86: wmi-mof: New driver to expose embedded WMI MOF
> > > > > metadata
> > > > >
> > > > > On Tuesday 06 June 2017 15:56:21 Pali Rohár wrote:
> > > > > > On Tuesday 06 June 2017 13:46:16 [email protected]
> > > > > >
> > > > > > wrote:
> > > > > > > 2) On my system when you expand the arguments for "void
> > > > > > > DoBFn" the source doesn't describe individual arguments
> > > > > > > like you do. Again this might not matter to MOF parsing
> > > > > > > tools but wanted to let you know in case it does.
> > > > > >
> > > > > > I know, this part is missing. Order of arguments are only
> > > > > > in ID qualifier and not sorted + in/out de-duplicated.
> > > > >
> > > > > Implemented! Now arguments are correctly placed based on ID
> > > > > qualifier.
> > > >
> > > > I think it's still off a little though.
> > > >
> > > > What I'm getting back now from bmf2mof is:
> > > > void DoBFn([in, Description("Fn buf"), out] BDat Data);
> > > >
> > > > Whereas source puts Description as the last argument:
> > > > void DoBFn([in, out, Description("Fn buf")] BDat Data);
> > >
> > > In BMOF from my Latitude E6440 there are specified two parameters
> > > with index 0. One with qualifiers ("in", Description("Fn buf"))
> > > and one with ("out", Description("Fn buf")). I think you have
> > > similar/same data in BMOF.
> > >
> > > In my bmf2mof I just combined those two parameters into one (when
> > > name, type and index matches) and concatenate also qualifiers
> > > with removing duplicates.
> > >
> > > Do not know what is correct way, but I think qualifiers are just
> > > unordered set. MS decompiler probably put "in" and "out"
> > > qualifiers before any other for better readability.
> >
> > Have you tried to run it through mofcomp.exe and then decompile
> > again with bmf2mof? As long as it's coming out the same you're
> > probably right.
>
> Yes, bmf2mof+mofcomp.exe+bmf2mof gives same output as just bmf2mof.
I changed order for printing qualifiers in bmf2mof. "in" and "out" are
now printed before all others. So you should see now same output.
> > > > > > > source:
> > > > > > > void DoBFn([in, out, Description("Fn buf")] BDat Data);
> > > > > > >
> > > > > > > bmf2mof:
> > > > > > > void doBFn([in, Description("Fn buf"), ID(0)] BDat
> > > > > > > Data,
> > > > > > > [out, Description("Fn buf"), ID(0)] BDat Data);
> > > > >
> > > > > --
> > > > > Pali Rohár
> > > > > [email protected]
> > >
> > > --
> > > Pali Rohár
> > > [email protected]
--
Pali Rohár
[email protected]