On Thu, Apr 13, 2017 at 08:32:48AM -0700, Andy Lutomirski wrote: > On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@xxxxxxxxxx> wrote: > >> Hi All, > >> > >> There are a few parallel efforts involving the Windows Management > >> Instrumentation (WMI)[1] and dependent/related drivers. I'd like to have a round of > >> discussion among those of you that have been involved in this space before we > >> decide on a direction. > >> > >> The WMI support in the kernel today fairly narrowly supports a handful of > >> systems. Andy L. has a work-in-progress series [2] which converts wmi into a > >> platform device and a proper bus, providing devices for dependent drivers to > >> bind to, and a mechanism for sibling devices to communicate with each other. > >> I've reviewed the series and feel like the approach is sound, I plan to carry > >> this series forward and merge it (with Andy L's permission). > >> > >> Are there any objections to this? > > > > Back in January 2016, I sent Andy a few minor comments about this > > series. A year later, I offered to iron out the remaining issues and > > resubmit the series in Andy's name when I find the time. Sadly, things > > have changed a bit for me since that time and it is unlikely that I will > > be able to deliver, for which I am sorry. > > > > However, browsing Andy's branch I see that most issues have been > > resolved, though I think some of my remarks [1] have either been missed > > or silently refuted :) > > > > Anyway, I also like this approach and I think this series is a valuable > > cleanup. > > Me too :) > > >> In Windows, applications interact with WMI more or less directly. We don't do > >> this in Linux currently, although it has been discussed in the past [3]. Some > >> vendors will work around this by performing SMI/SMM, which is inefficient at > >> best. Exposing WMI methods to userspace would bring parity to WMI for Linux and > >> Windows. > >> > >> There are two principal concerns I'd appreciate your thoughts on: > >> > >> a) As an undiscoverable interface (you need to know the method signatures ahead > >> of time), universally exposing every WMI "device" to userspace seems like "a bad > >> idea" from a security and stability perspective. While access would certainly be > >> privileged, it seems more prudent to make this exposure opt-in. We also handle > >> some of this with kernel drivers and exposing those "devices" to userspace would > >> enable userspace and the kernel to fight over control. So - if we expose WMI > >> devices to userspace, I believe this should be done on a case by case basis, > >> opting in, and not by default as part of the WMI driver (although it can provide > >> the mechanism for a sub-driver to use), and possibly a devmode to do so by > >> default. > > I agree. I don't want too see gnome-whatever-widget talking directly > to WMI and confusing the kernel driver for the same thing. > > >> Secondarily, Andy L created a simple driver to expose the MOF buffer [2] to > >> userspace which could be consumed by a userspace tool to create sources for an > >> interface to the exposed WMI methods. > > > > +1 for the idea, it makes figuring out what the firmware actually > > exposes through WMI a bit easier. After skimming through the driver's > > code, I would only recommend to review the included headers > > (linux/input/sparse-keymap.h, linux/dmi.h and acpi/video.h all seem > > redundant to me). > > > > What we still need, though, is an open source version of wmiofck.exe. I > > am unaware of anything like that existing and installing the Windows > > Driver Kit just to run one command which spits out a single *.h file is > > not something I would describe as convenient (been there). > > I haven't tried to see whether they do what's needed, but there's > OpenWBEM and OpenPegasus. > > Anyway, if such a tool exists, it would be handy to expose the binary > MOF data to userspace so the tool could be used to help get WMI > working on new platforms. > Looking into what exists and what it might take to write a new tool is on my todo list as a second priority to sorting out the WMI userspace mechanism issue. Thanks for the pointers. -- Darren Hart VMware Open Source Technology Center
