Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753426AbdDMNmL (ORCPT ); Thu, 13 Apr 2017 09:42:11 -0400 Received: from esa1.dell-outbound.iphmx.com ([68.232.153.90]:16109 "EHLO esa1.dell-outbound.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751054AbdDMNmJ (ORCPT ); Thu, 13 Apr 2017 09:42:09 -0400 X-Greylist: delayed 740 seconds by postgrey-1.27 at vger.kernel.org; Thu, 13 Apr 2017 09:42:08 EDT From: X-LoopCount0: from 10.170.28.40 X-IronPort-AV: E=Sophos;i="5.37,194,1488866400"; d="scan'208";a="94097125" To: , CC: , , , , , , , , Subject: RE: RFC: WMI Enhancements Thread-Topic: RFC: WMI Enhancements Thread-Index: AQHSs+HFfWGz3Na/pUazu2XvXvLesqHDPEIAgAANzoA= Date: Thu, 13 Apr 2017 13:29:41 +0000 Message-ID: <3370431810bd4bc09fd9eb16eb9abea5@ausx13mpc120.AMER.DELL.COM> References: <20170412230854.GA11963@fury> <20170413073228.GB1462@ozzy.nask.waw.pl> In-Reply-To: <20170413073228.GB1462@ozzy.nask.waw.pl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.208.86.26] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v3DDgES5005547 Content-Length: 5649 Lines: 115 > -----Original Message----- > From: Michał Kępień [mailto:kernel@kempniu.pl] > Sent: Thursday, April 13, 2017 2:32 AM > To: Darren Hart > Cc: Rafael Wysocki ; Len Brown ; > Pali Rohár ; Corentin Chary > ; Limonciello, Mario > ; Andy Lutomirski ; Andy > Shevchenko ; LKML kernel@vger.kernel.org>; platform-driver-x86@vger.kernel.org; linux- > pm@vger.kernel.org > Subject: Re: RFC: WMI Enhancements > > > 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. > > > 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. > > > > b) The mechanism to expose WMI devices to userspace must allow for > > atomic operation, which would exclude a sysfs interface involving multiple > files. > > Something like an ioctl or a char dev would be more appropriate. > > > > Does anyone think differently regarding a) or b) ? > > Please pardon my ignorance, but what do we actually gain by exposing WMI to > userspace? Enabling applications to fetch SMBIOS data? We already have an > interface for that. Enabling applications to receive input events? Likewise. Input notifications are just one aspect that received over WMI. I don't see any reason to move the notifications out of the kernel. In terms of userspace applications, once a WMI interface to userspace is available libsmbios would change over to that. Applications using libsmbios would benefit. > You mentioned WMI's efficiency compared to SMI/SMM, but is it a difference > significant enough for anyone to notice? At least for Dell there are optimizations being made when data is requested over the WMI-ACPI wrapper instead of directly via SMI/SMM. For example if the data is a "static" table or the request is to something that is passed thru to the EC it's a big waste of effort to put the CPU in SMM. The savings there is significant. > > I am biased here as I have had my own struggles with WMI in the past, but it > looks like a layer of indirection which brings little value, yet is tricky to expose > properly. If there is a real-life use case that makes this idea worthwhile, I > would love to be enlightened. > > > 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). > > [1] https://www.spinics.net/lists/platform-driver-x86/msg08201.html > > -- > Best regards, > Michał Kępień