Re: RFC: WMI Enhancements

[Darren Hart <dvhart@infradead.org>]

On Thu, Apr 13, 2017 at 09:33:39AM +0200, Pali Rohár wrote:
> On Wednesday 12 April 2017 16:08:54 Darren Hart wrote:
> > 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.
> 
> Maybe we should first ask, why linux userspace applications need direct
> access to WMI? If we look at current WMI linux drivers, basically every
> one translate WMI interface to some standard linux class driver (with
> some extensions). This is something which should stay in kernel. E.g.
> rfkill, backlight, led, input keyboard, ...

Agreed on these common functions. Whenever we have a common subsystem / class
driver, we should make use of that. This is another good reason not to publish
all WMI methods wholesale to userspace. That said, class drivers are written
after we eventually see a pattern in drivers and refactor them to encapsulate a
common functionality. This takes time, and is only worth doing for things that
are truly common.

WMI (Windows Management Instrumentation) is very generic and is intended to
provide vendors the ability to manage and configure the systems at the firmware
level.

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 :-)

-- 
Darren Hart
VMware Open Source Technology Center