Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753299AbdDMPkr (ORCPT ); Thu, 13 Apr 2017 11:40:47 -0400 Received: from esa3.dell-outbound.iphmx.com ([68.232.153.94]:59431 "EHLO esa3.dell-outbound.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751598AbdDMPkp (ORCPT ); Thu, 13 Apr 2017 11:40:45 -0400 From: X-LoopCount0: from 10.175.216.251 X-IronPort-AV: E=Sophos;i="5.37,195,1488866400"; d="scan'208";a="94139663" To: , CC: , , , , , , , , , Subject: RE: RFC: WMI Enhancements Thread-Topic: RFC: WMI Enhancements Thread-Index: AQHSs+HFfWGz3Na/pUazu2XvXvLesqHDPEIAgAANzoCAAFv3AP//yFaw Date: Thu, 13 Apr 2017 15:40:41 +0000 Message-ID: References: <20170412230854.GA11963@fury> <20170413073228.GB1462@ozzy.nask.waw.pl> <3370431810bd4bc09fd9eb16eb9abea5@ausx13mpc120.AMER.DELL.COM> <20170413135102.GL3090@pali> In-Reply-To: <20170413135102.GL3090@pali> 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 v3DFepIN017692 Content-Length: 2319 Lines: 56 > -----Original Message----- > From: Pali Rohár [mailto:pali.rohar@gmail.com] > Sent: Thursday, April 13, 2017 8:51 AM > To: Limonciello, Mario ; Hans de Goede > > Cc: kernel@kempniu.pl; dvhart@infradead.org; rjw@rjwysocki.net; > len.brown@intel.com; corentin.chary@gmail.com; luto@kernel.org; > andriy.shevchenko@linux.intel.com; linux-kernel@vger.kernel.org; platform- > driver-x86@vger.kernel.org; linux-pm@vger.kernel.org > Subject: Re: RFC: WMI Enhancements > > On Thursday 13 April 2017 13:29:41 Mario.Limonciello@dell.com wrote: > > > 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. > > Really libsmbios matters here? Hans (added to thread) wrote that libsmbios is > a relic, something of ages long gone by and a normal user should never use it. > A normal user shouldn't be using it directly, but libsmbios is used by a few open source tools as a dependency. It's also used in many Dell manageability tools. > If this is truth and libsmbios should not be used, then we probably do not need > to care about it in changes for WMI. > > Hans, Mario, any comment/clarification about it? > > > > 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. > > Maybe we can use this Dell WMI-ACPI wrapper for kernel drivers instead of > current SMI/SMM direct access? > > -- > Pali Rohár > pali.rohar@gmail.com