RE: RFC: WMI Enhancements

[Mario.Limonciello]

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@xxxxxxxxxxxxx]
> Sent: Friday, April 14, 2017 1:28 PM
> To: Limonciello, Mario <Mario_Limonciello@xxxxxxxx>
> Cc: pali.rohar@xxxxxxxxx; rjw@xxxxxxxxxxxxx; len.brown@xxxxxxxxx;
> corentin.chary@xxxxxxxxx; luto@xxxxxxxxxx; andriy.shevchenko@xxxxxxxxxxxxxxx;
> linux-kernel@xxxxxxxxxxxxxxx; platform-driver-x86@xxxxxxxxxxxxxxx; linux-
> pm@xxxxxxxxxxxxxxx
> Subject: Re: RFC: WMI Enhancements
> 
> On Fri, Apr 14, 2017 at 05:42:03PM +0000, Mario.Limonciello@xxxxxxxx wrote:
> >
> >
> > > -----Original Message-----
> > > From: Darren Hart [mailto:dvhart@xxxxxxxxxxxxx]
> > > Sent: Thursday, April 13, 2017 6:51 PM
> > > To: Limonciello, Mario <Mario_Limonciello@xxxxxxxx>
> > > Cc: pali.rohar@xxxxxxxxx; rjw@xxxxxxxxxxxxx; len.brown@xxxxxxxxx;
> > > corentin.chary@xxxxxxxxx; luto@xxxxxxxxxx;
> andriy.shevchenko@xxxxxxxxxxxxxxx;
> > > linux-kernel@xxxxxxxxxxxxxxx; platform-driver-x86@xxxxxxxxxxxxxxx; linux-
> > > pm@xxxxxxxxxxxxxxx
> > > Subject: Re: RFC: WMI Enhancements
> > >
> > > On Thu, Apr 13, 2017 at 08:38:28PM +0000, Mario.Limonciello@xxxxxxxx
> 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.