On Tue, Aug 1, 2017 at 3:39 PM, Darren Hart <dvhart@xxxxxxxxxxxxx> 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
