Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756175AbdDMUid (ORCPT ); Thu, 13 Apr 2017 16:38:33 -0400 Received: from esa7.dell-outbound.iphmx.com ([68.232.153.96]:4957 "EHLO esa7.dell-outbound.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751492AbdDMUib (ORCPT ); Thu, 13 Apr 2017 16:38:31 -0400 From: X-LoopCount0: from 10.170.28.40 X-IronPort-AV: E=Sophos;i="5.37,195,1488866400"; d="scan'208";a="6261376" To: , CC: , , , , , , , Subject: RE: RFC: WMI Enhancements Thread-Topic: RFC: WMI Enhancements Thread-Index: AQHSs+HFfWGz3Na/pUazu2XvXvLesqHDPJeAgACdVQD//+SO8A== Date: Thu, 13 Apr 2017 20:38:28 +0000 Message-ID: References: <20170412230854.GA11963@fury> <20170413073339.GH3090@pali> <20170413165646.GD2064@fury> In-Reply-To: <20170413165646.GD2064@fury> 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="iso-8859-1" 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 quoted-printable to 8bit by mail.home.local id v3DKdAhx022766 Content-Length: 1768 Lines: 36 Earlier question from Andy. I had some discussion with the right people about this. > Is it just the "call SMBIOS" GUID or are there other things? Today - it's just the SMBIOS calling GUID. There are plans (not yet concrete) for splitting up data access and organization of that data access classes across multiple other GUID/method pairs in the future. Ideally this could be done without needing kernel patches every time a new GUID would (essentially) need to be whitelisted. > I am a strong supporter of the following philosophy with respect to supporting > innovation: > "Enable them to enable themselves and get out of their way" > > I've followed this approach over the years to encourage upstream first software > development, open-first policy toward specifications and documentation, proper > license selection, and development of new mechanisms in existing standards, like > ACPI _DSD. All of these serve to support innovation by removing bottlenecks and > enabling developers to be independent. > > What I don't want to see is the Linux kernel becoming a bottleneck to feature > parity with Windows (or to becoming the lead vehicle for new features). When a > vendor has a feature they want to expose which they determine to be a value > proposition for their product, I don't want the lack of a class driver to get in > the way. Exposing specific GUIDs is a minimal and easy to upstream change which > would enable rapid feature enabling. > > Perhaps I should have led with this :-) > So considering future plans, I'd really like if it's possible to expose all the GUID's the GUID's the same as Windows does today. As example is we have some diagnostic testing tools. Having to whitelist interfaces for them to operate would be sub-optimal.