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 /debug/wmi/<GUID>/_wdg would be the most appropriate location for these. -- Darren Hart VMware Open Source Technology Center
