Re: [PATCH 3/3] platform/wmi: Expose the raw WDG data in sysfs

[Andy Lutomirski <luto@kernel.org>]

On Tue, Aug 1, 2017 at 3:39 PM, Darren Hart <dvhart@infradead.org> wrote:
> On Tue, Aug 01, 2017 at 11:31:12PM +0200, Pali Rohár wrote:
>> On Tuesday 01 August 2017 14:17:02 Darren Hart wrote:
> ...
>> > My understanding of the BMOF data is that it provided us "with a description of
>> > all data blocks, WMI methods, and events for the device" [1].
>> >
>> > If that's accurate, why do we need the _WDG? This just seems contrary to what
>> > the BMOF data is supposed to be for.
>>
>> BMOF provides mapping from human class and method names to WMI GUID. WDG
>> then provides mapping from WMI GUID to ACPI function names.
>>
>> Therefore if you upper layer in MOF world say that it want to call
>> method M of class C and you want to know which ACPI function is called,
>> you need to parse both BMOF and WDG to get mapping from MOF to ACPI.
>> Same for WMI events.
>>
>> > > Ideally ability to create dump of BMOF and WDG on one computer and then
>> > > parse those data on another.
>> > >
>> > > Having original BMOF and WDG structures is a good for debugging and
>> > > development purpose.
>
> OK, I went and reviewed the MOF docs, our previous discussions, and your bmf2moc
> code (awesome by the way). So, agreed - we need easy access to _WDG and BMOF for
> development purposes.
>
> Having the kernel expose a guid/class/method interface should provide the
> abstraction Rafael called for.
>
> The question then, is should these two things be in sysfs, where they become
> more or less permanent, or are they better off in debugfs, where they can be
> used by developers as needed, but are not present on production systems, and
> we are not bound to the representation we use from now until forever.
>
> Seems to me:
>
> /debug/wmi/<GUID>/bmof

I can imagine a real production userspace app that parses BMOF data.
Imagine you write a thingy that calls some laptop method foo(1) where
foo is defined in the MOF.  You could hardcode the mapping to the
GUID, but you could also parse the BMOF.

> /debug/wmi/<GUID>/_wdg

More like /debug/wmi/<bus name>/_wdg, but yes.  I wish there was a
standard way to make a debugfs directory corresponding to a sysfs
path.  Maybe this exists -- I'll look.

FWIW, almost all the _WDG data is already there in sysfs in Linus'
tree.  See, for example, cat
/sys/devices/platform/PNP0C14:01/wmi_bus/wmi_bus-PNP0C14:01/05901221-D566-11D1-B2F0-00A0C9062910/object_id

--Andy

>
> would be the most appropriate location for these.
>
> --
> Darren Hart
> VMware Open Source Technology Center