Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1622607 > unrolled thread

RFC: WMI Enhancements

Back to article view | Back to linux.kernel

Contents

  RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-13 01:10 +0200
    Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-13 09:40 +0200
      Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-13 19:00 +0200
        RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 22:40 +0200
          Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-14 02:00 +0200
            RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-14 19:50 +0200
              Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-14 20:30 +0200
                RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-14 21:10 +0200
    Re: RFC: WMI Enhancements Michał Kępień <kernel@kempniu.pl> - 2017-04-13 09:40 +0200
      RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 15:50 +0200
        Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-13 16:00 +0200
          Re: RFC: WMI Enhancements Andy Lutomirski <luto@kernel.org> - 2017-04-13 17:40 +0200
            RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 18:00 +0200
              Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-13 18:10 +0200
          RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 17:50 +0200
            Re: RFC: WMI Enhancements Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2017-04-18 12:00 +0200
              RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-18 16:10 +0200
      Re: RFC: WMI Enhancements Andy Lutomirski <luto@kernel.org> - 2017-04-13 17:40 +0200
        Re: RFC: WMI Enhancements Andy Lutomirski <luto@kernel.org> - 2017-04-13 17:50 +0200
          Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-13 18:20 +0200
        Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-13 17:50 +0200
        Re: RFC: WMI Enhancements Andy Lutomirski <luto@kernel.org> - 2017-04-13 18:00 +0200
          RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 19:00 +0200
            Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-13 19:10 +0200
              Re: RFC: WMI Enhancements Andy Lutomirski <luto@kernel.org> - 2017-04-13 19:50 +0200
                RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 20:00 +0200
              RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 19:50 +0200
                Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-18 10:00 +0200
                  Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-18 19:00 +0200
                    Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-18 21:30 +0200
        RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 18:00 +0200
          Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-13 19:10 +0200
            Re: RFC: WMI Enhancements Andy Lutomirski <luto@kernel.org> - 2017-04-13 19:40 +0200
              RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-13 19:50 +0200
        Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-13 18:10 +0200
    Re: RFC: WMI Enhancements "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-04-15 01:00 +0200
      Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-15 01:10 +0200
        Re: RFC: WMI Enhancements Andy Lutomirski <luto@amacapital.net> - 2017-04-18 00:10 +0200
          Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-18 01:20 +0200
            Re: RFC: WMI Enhancements "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-04-18 15:20 +0200
              Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-18 18:40 +0200
                Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-18 21:30 +0200
                  Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-19 00:50 +0200
                    Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-19 10:00 +0200
                      RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-19 18:40 +0200
                        Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-19 19:00 +0200
                          RE: RFC: WMI Enhancements <Mario.Limonciello@dell.com> - 2017-04-19 19:30 +0200
                            Re: RFC: WMI Enhancements Pali Rohár <pali.rohar@gmail.com> - 2017-04-20 15:20 +0200
                              Re: RFC: WMI Enhancements Darren Hart <dvhart@infradead.org> - 2017-04-20 22:50 +0200
                          Re: RFC: WMI Enhancements Christoph Hellwig <hch@infradead.org> - 2017-04-20 16:20 +0200
                Re: RFC: WMI Enhancements "Rafael J. Wysocki" <rafael@kernel.org> - 2017-04-18 23:20 +0200

Page 1 of 3  [1] 2 3  Next page →

#1622607 — 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?

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

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. With or without MOF support however, I
think it makes sense to provide a common WMI mechanism to expose specific
devices/methods to userspace.

Appreciate your thoughts,

References:
1. https://msdn.microsoft.com/en-us/library/windows/hardware/Dn614028(v=vs.85).aspx
2. https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=platform/wmi
3. https://www.mail-archive.com/linux-acpi@vger.kernel.org/msg11686.html

-- 
Darren Hart
VMware Open Source Technology Center

[toc] | [next] | [standalone]

#1622778

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, ...

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

#1623189

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

[toc] | [prev] | [next] | [standalone]

#1623338

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.

[toc] | [prev] | [next] | [standalone]

#1623439

On Thu, Apr 13, 2017 at 08:38:28PM +0000, Mario.Limonciello@dell.com wrote:
> 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.

A bit of trouble parsing... to be clear, your preference would be that for the
PNP0C14 on whitelisted platforms (either DMI matches, or possibly via the ACPI
Device UID?) we expose every GUID (Method, Event, and Data) for that device to
userspace?

The concern raised here is that for systems using dell-wmi, the two GUIDs used
by the kernel would also be exposed to userspace. Is this correct?

> 
> As example is we have some diagnostic testing tools.  Having to whitelist interfaces
> for them to operate would be sub-optimal.
> 

Is this a problem because there are a lot of them, or because they routinely
change?

Also, are these something that could be part of a debug feature, or do they need
to be in production so you can work with customers to diagnose running systems
for example?

-- 
Darren Hart
VMware Open Source Technology Center

[toc] | [prev] | [next] | [standalone]

#1623813

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@infradead.org]
> Sent: Thursday, April 13, 2017 6:51 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: pali.rohar@gmail.com; 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 Thu, Apr 13, 2017 at 08:38:28PM +0000, Mario.Limonciello@dell.com wrote:
> > 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.
> 
> A bit of trouble parsing... to be clear, your preference would be that for the
> PNP0C14 on whitelisted platforms (either DMI matches, or possibly via the ACPI
> Device UID?) we expose every GUID (Method, Event, and Data) for that device to
> userspace?

My preference would be to expose everything found in _WDG across platforms so it 
doesn't have to be a whitelist.  DMI matching could work if it was done specifically
on the manufacturer rather than individual system.

If you compare to how it's done with the other OS, everything mentioned in the MOF
is accessible from userspace.  The only reason the MOF exists is to match up
what's in _WDG.  Linux can make this actually easier in that you just don't use the
MOF at all.

> 
> The concern raised here is that for systems using dell-wmi, the two GUIDs used
> by the kernel would also be exposed to userspace. Is this correct?
> 
> >
> > As example is we have some diagnostic testing tools.  Having to whitelist
> interfaces
> > for them to operate would be sub-optimal.
> >
> 
> Is this a problem because there are a lot of them, or because they routinely
> change?

They're going to be changing in the future and that will use a new WMI interface
when that change happens.

The interfaces don't routinely change today, but there discussions to change
and introduce more later.

> 
> Also, are these something that could be part of a debug feature, or do they need
> to be in production so you can work with customers to diagnose running systems
> for example?
> 

The intent is for production, so that remediation tools can run on the box.

[toc] | [prev] | [next] | [standalone]

#1623833

On Fri, Apr 14, 2017 at 05:42:03PM +0000, Mario.Limonciello@dell.com wrote:
> 
> 
> > -----Original Message-----
> > From: Darren Hart [mailto:dvhart@infradead.org]
> > Sent: Thursday, April 13, 2017 6:51 PM
> > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > Cc: pali.rohar@gmail.com; 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 Thu, Apr 13, 2017 at 08:38:28PM +0000, Mario.Limonciello@dell.com wrote:
> > > 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.
> > 
> > A bit of trouble parsing... to be clear, your preference would be that for the
> > PNP0C14 on whitelisted platforms (either DMI matches, or possibly via the ACPI
> > Device UID?) we expose every GUID (Method, Event, and Data) for that device to
> > userspace?
> 
> My preference would be to expose everything found in _WDG across platforms so it 
> doesn't have to be a whitelist.  DMI matching could work if it was done specifically
> on the manufacturer rather than individual system.
> 
> If you compare to how it's done with the other OS, everything mentioned in the MOF
> is accessible from userspace.  The only reason the MOF exists is to match up
> what's in _WDG.  Linux can make this actually easier in that you just don't use the
> MOF at all.
> 
> > 
> > The concern raised here is that for systems using dell-wmi, the two GUIDs used
> > by the kernel would also be exposed to userspace. Is this correct?

OK, rather than whitelisting specific GUIDs to be exported, what if we matched
on a vendor and exported all of them except for the ones that any kernel drivers
have already bound to? For example, dell-wmi currently binds to:

#define DELL_EVENT_GUID "9DBB5994-A997-11DA-B012-B622A1EF5492"
#define DELL_DESCRIPTOR_GUID "8D9DDCBC-A997-11DA-B012-B622A1EF5492"

Perhaps a set of mof and $vendor-mof drivers could be created which would do what
Andy L's patch does, but match on DMI Vendor or WMI PNP UID and export all
interfaces. When another kernel driver binds to a WMI GUID, that GUID will
either not be exported, or it will be "locked" from a userspace perspective.

This of course is dependent on whether or not the WMI GUIDs are granular enough
or if the same GUID is needed by the userpsace application AND by the kernel
driver to perform different functions - this would be really unfortunate.

That said, from what I've learned about WMI, it was designed to provide access
to firmware from userspace. The approach we take in Linux currently was
expedient, but not consistent with the intent of the mechanism.

> > 
> > >
> > > As example is we have some diagnostic testing tools.  Having to whitelist
> > interfaces
> > > for them to operate would be sub-optimal.
> > >
> > 
> > Is this a problem because there are a lot of them, or because they routinely
> > change?
> 
> They're going to be changing in the future and that will use a new WMI interface
> when that change happens.
> 
> The interfaces don't routinely change today, but there discussions to change
> and introduce more later.
> 
> > 
> > Also, are these something that could be part of a debug feature, or do they need
> > to be in production so you can work with customers to diagnose running systems
> > for example?
> > 
> 
> The intent is for production, so that remediation tools can run on the box.
> 
> 

-- 
Darren Hart
VMware Open Source Technology Center

[toc] | [prev] | [next] | [standalone]

#1623866

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@infradead.org]
> Sent: Friday, April 14, 2017 1:28 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: pali.rohar@gmail.com; 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 Fri, Apr 14, 2017 at 05:42:03PM +0000, Mario.Limonciello@dell.com wrote:
> >
> >
> > > -----Original Message-----
> > > From: Darren Hart [mailto:dvhart@infradead.org]
> > > Sent: Thursday, April 13, 2017 6:51 PM
> > > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > > Cc: pali.rohar@gmail.com; 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 Thu, Apr 13, 2017 at 08:38:28PM +0000, Mario.Limonciello@dell.com
> wrote:
> > > > 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.
> > >
> > > A bit of trouble parsing... to be clear, your preference would be that for the
> > > PNP0C14 on whitelisted platforms (either DMI matches, or possibly via the ACPI
> > > Device UID?) we expose every GUID (Method, Event, and Data) for that device to
> > > userspace?
> >
> > My preference would be to expose everything found in _WDG across platforms so
> it
> > doesn't have to be a whitelist.  DMI matching could work if it was done
> specifically
> > on the manufacturer rather than individual system.
> >
> > If you compare to how it's done with the other OS, everything mentioned in the
> MOF
> > is accessible from userspace.  The only reason the MOF exists is to match up
> > what's in _WDG.  Linux can make this actually easier in that you just don't use the
> > MOF at all.
> >
> > >
> > > The concern raised here is that for systems using dell-wmi, the two GUIDs used
> > > by the kernel would also be exposed to userspace. Is this correct?
> 
> OK, rather than whitelisting specific GUIDs to be exported, what if we matched
> on a vendor and exported all of them except for the ones that any kernel drivers
> have already bound to? For example, dell-wmi currently binds to:
> 
> #define DELL_EVENT_GUID "9DBB5994-A997-11DA-B012-B622A1EF5492"
> #define DELL_DESCRIPTOR_GUID "8D9DDCBC-A997-11DA-B012-B622A1EF5492"
> 
> Perhaps a set of mof and $vendor-mof drivers could be created which would do
> what
> Andy L's patch does, but match on DMI Vendor or WMI PNP UID and export all
> interfaces. When another kernel driver binds to a WMI GUID, that GUID will
> either not be exported, or it will be "locked" from a userspace perspective.
> 
> This of course is dependent on whether or not the WMI GUIDs are granular enough
> or if the same GUID is needed by the userpsace application AND by the kernel
> driver to perform different functions - this would be really unfortunate.
> 
> That said, from what I've learned about WMI, it was designed to provide access
> to firmware from userspace. The approach we take in Linux currently was
> expedient, but not consistent with the intent of the mechanism.
> 

For $FUTURE GUIDs that approach could potentially work depending upon how
the different GUID's are segmented.  There's a few different approaches being
discussed.

It unfortunately wouldn't work with the "current" stuff though if we go forward
with the proposal to adjust dell-smbios to use the WMI calls too.
The SMBIOS GUID(A80593CE-A997-11DA-B012-B622A1EF5492) would get 
taken by dell-smbios and hence not available to userspace.

It would be fine to restrict the event one (9DBB5994-A997-11DA-B012-B622A1EF5492).
The one the kernel sees as DESCRIPTOR_GUID can be used to provide static
Info, I don't think that's needed by userspace either.

[toc] | [prev] | [next] | [standalone]

#1622782

> 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.  You mentioned WMI's efficiency compared to SMI/SMM,
but is it a difference significant enough for anyone to notice?

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ń

[toc] | [prev] | [next] | [standalone]

#1623041

> -----Original Message-----
> From: Michał Kępień [mailto:kernel@kempniu.pl]
> Sent: Thursday, April 13, 2017 2:32 AM
> To: Darren Hart <dvhart@infradead.org>
> Cc: Rafael Wysocki <rjw@rjwysocki.net>; Len Brown <len.brown@intel.com>;
> Pali Rohár <pali.rohar@gmail.com>; Corentin Chary
> <corentin.chary@gmail.com>; Limonciello, Mario
> <Mario_Limonciello@Dell.com>; Andy Lutomirski <luto@kernel.org>; Andy
> Shevchenko <andriy.shevchenko@linux.intel.com>; LKML <linux-
> 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ń

[toc] | [prev] | [next] | [standalone]

#1623052

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.

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

[toc] | [prev] | [next] | [standalone]

#1623126

On Thu, Apr 13, 2017 at 6:51 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> 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.
>
> 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?
>

This would make sense to me.  IIRC the only functional difference is
the way that pointers are handled.  It shouldn't be that hard to make
it work for both variants, though.  It could look like:

buf = dell_smbios_alloc(...);
dell_smbios_put_pointer(buf, offset of pointer, offset of pointee);
dell_smbios_call(buf);

or similar.

[toc] | [prev] | [next] | [standalone]

#1623138

> -----Original Message-----
> From: Andy Lutomirski [mailto:luto@kernel.org]
> Sent: Thursday, April 13, 2017 10:35 AM
> To: Pali Rohár <pali.rohar@gmail.com>
> Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; Hans de Goede
> <hdegoede@redhat.com>; Michał Kępień <kernel@kempniu.pl>; Darren Hart
> <dvhart@infradead.org>; Rafael J. Wysocki <rjw@rjwysocki.net>; Len Brown
> <len.brown@intel.com>; corentin.chary@gmail.com; Andrew Lutomirski
> <luto@kernel.org>; Andy Shevchenko <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 Thu, Apr 13, 2017 at 6:51 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > 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.
> >
> > 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?
> >
> 
> This would make sense to me.  IIRC the only functional difference is the way
> that pointers are handled.  It shouldn't be that hard to make it work for both
> variants, though.  It could look like:
> 
> buf = dell_smbios_alloc(...);
> dell_smbios_put_pointer(buf, offset of pointer, offset of pointee);
> dell_smbios_call(buf);
> 
> or similar.

Yes, I was going to encourage that kernel change after this WMI discussion 
had some conclusions.

[toc] | [prev] | [next] | [standalone]

#1623150

On Thu, Apr 13, 2017 at 03:40:08PM +0000, Mario.Limonciello@dell.com wrote:
> > -----Original Message-----
> > From: Andy Lutomirski [mailto:luto@kernel.org]
> > Sent: Thursday, April 13, 2017 10:35 AM
> > To: Pali Rohár <pali.rohar@gmail.com>
> > Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; Hans de Goede
> > <hdegoede@redhat.com>; Michał Kępień <kernel@kempniu.pl>; Darren Hart
> > <dvhart@infradead.org>; Rafael J. Wysocki <rjw@rjwysocki.net>; Len Brown
> > <len.brown@intel.com>; corentin.chary@gmail.com; Andrew Lutomirski
> > <luto@kernel.org>; Andy Shevchenko <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 Thu, Apr 13, 2017 at 6:51 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > > 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.
> > >
> > > 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?
> > >
> > 
> > This would make sense to me.  IIRC the only functional difference is the way
> > that pointers are handled.  It shouldn't be that hard to make it work for both
> > variants, though.  It could look like:
> > 
> > buf = dell_smbios_alloc(...);
> > dell_smbios_put_pointer(buf, offset of pointer, offset of pointee);
> > dell_smbios_call(buf);
> > 
> > or similar.
> 
> Yes, I was going to encourage that kernel change after this WMI discussion 
> had some conclusions.

Agreed on this point as well.

-- 
Darren Hart
VMware Open Source Technology Center

[toc] | [prev] | [next] | [standalone]

#1623133

> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Thursday, April 13, 2017 8:51 AM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>; Hans de Goede
> <hdegoede@redhat.com>
> 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

[toc] | [prev] | [next] | [standalone]

#1625196

On Thu, 2017-04-13 at 15:40 +0000, Mario.Limonciello@dell.com wrote:
> > 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.
> 

Shouldn't tools evolve to use newer interfaces (while keeping
compatibility with old kernels)?

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

[toc] | [prev] | [next] | [standalone]

#1625347

> -----Original Message-----
> From: Andy Shevchenko [mailto:andriy.shevchenko@linux.intel.com]
> Sent: Tuesday, April 18, 2017 2:37 AM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>; pali.rohar@gmail.com;
> hdegoede@redhat.com
> Cc: kernel@kempniu.pl; dvhart@infradead.org; rjw@rjwysocki.net;
> len.brown@intel.com; corentin.chary@gmail.com; luto@kernel.org; linux-
> kernel@vger.kernel.org; platform-driver-x86@vger.kernel.org; linux-
> pm@vger.kernel.org
> Subject: Re: RFC: WMI Enhancements
> 
> On Thu, 2017-04-13 at 15:40 +0000, Mario.Limonciello@dell.com wrote:
> > > 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.
> >
> 
> Shouldn't tools evolve to use newer interfaces (while keeping
> compatibility with old kernels)?

Yes.  If a WMI userspace interface does end up being the outcome of
this thread, I'll push the relevant folks maintaining those tools to switch
over so that dcdbas can be marked deprecated and only in use for older
kernels.

[toc] | [prev] | [next] | [standalone]

#1623123

On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.pl> 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.

[toc] | [prev] | [next] | [standalone]

#1623129

On Thu, Apr 13, 2017 at 8:39 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Thursday 13 April 2017 17:32:48 Andy Lutomirski wrote:
>> On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.pl>
>> wrote:
>> > 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.
>
> In this case, when WMI stay in kernel, MOF data could be exported via
> debugfs? I think there is no need to have them in sysfs stable ABI. As
> above usage (get WMI working on new platforms) looks like for debugging
> purpose.
>

That's a reasonable point.

[toc] | [prev] | [next] | [standalone]

#1623155

On Thu, Apr 13, 2017 at 08:44:28AM -0700, Andy Lutomirski wrote:
> On Thu, Apr 13, 2017 at 8:39 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > On Thursday 13 April 2017 17:32:48 Andy Lutomirski wrote:
> >> On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień <kernel@kempniu.pl>
> >> wrote:
> >> > 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.
> >
> > In this case, when WMI stay in kernel, MOF data could be exported via
> > debugfs? I think there is no need to have them in sysfs stable ABI. As
> > above usage (get WMI working on new platforms) looks like for debugging
> > purpose.
> >
> 
> That's a reasonable point.
> 

Also agreed.

-- 
Darren Hart
VMware Open Source Technology Center

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.kernel

csiph-web