RE: RFC: WMI Enhancements

[<Mario.Limonciello@dell.com>]

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