On Tue, Aug 01, 2017 at 10:40:40PM +0200, Pali Rohár wrote: > On Tuesday 01 August 2017 13:19:16 Andy Lutomirski wrote: > > On Tue, Aug 1, 2017 at 1:03 PM, Darren Hart <dvhart@xxxxxxxxxxxxx> wrote: > > > On Tue, Aug 01, 2017 at 08:37:28AM -0700, Andy Lutomirski wrote: > > >> This adds a sysfs binary attribute 'wdg' on the bus device > > >> (i.e. /sys/class/wmi_bus/wmi_bus-*/wdg) that contains the raw _WDG > > >> data from ACPI. This can be used along with the wmi-bmof driver to > > >> decode the raw interface data from ACPI. > > > > > > I don't recall seeing mention of this is the documentation I read as a > > > requirement to decoding the interface with the bmof. Do Windows systems export > > > _WDG to userspace? > > > > > > Why do we need to export _WDG? > > > > This was a feature that Pali asked for. Pali, since you seem to be > > working on userspace tooling, can you explain exactly what you'd use > > it for? > > Take raw BMOF and WDG buffers from ACPI and parse them in userspace. > Then provide needed information like mapping from MOF event name to ACPI > event name based on info from WDG buffer. > So first, I'm not opposed to adding it if that's what needed. However, I don't want to start pushing ACPI objects to sysfs without: 1) Confirming it's necessary 2) Getting Rafael's take on this practice, as if this is to become something we do, some kind of ACPI_OBJECT_SYSFS_EXPORT macro provided by ACPI would probably be the right way to do it. 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. > 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. For debugging purposes, the fwts and acpidump tools will provide this. > > On my laptop, at the very least, it would allow user code to determine > > that there's a WMI GUID that doesn't show up in sysfs. It doesn't > > show up in sysfs because the ACPI methods are completely missing, but > > it's still there in WDG. This prints a warning when wmi.ko is loaded, > > but maybe the userspace tooling would care, for debugging if nothing > > else. In this case, I'd argue userspace should only be aware of what the kernel decides to expose, based on, at the very least, compliance with the WMI documentation. 1. https://wiki.ubuntu.com/Kernel/Reference/WMI -- Darren Hart VMware Open Source Technology Center
