> -----Original Message----- > From: Darren Hart [mailto:dvh...@infradead.org] > Sent: Friday, April 14, 2017 1:28 PM > To: Limonciello, Mario <mario_limoncie...@dell.com> > Cc: pali.ro...@gmail.com; r...@rjwysocki.net; len.br...@intel.com; > corentin.ch...@gmail.com; l...@kernel.org; andriy.shevche...@linux.intel.com; > linux-kernel@vger.kernel.org; platform-driver-...@vger.kernel.org; linux- > p...@vger.kernel.org > Subject: Re: RFC: WMI Enhancements > > On Fri, Apr 14, 2017 at 05:42:03PM +0000, mario.limoncie...@dell.com wrote: > > > > > > > -----Original Message----- > > > From: Darren Hart [mailto:dvh...@infradead.org] > > > Sent: Thursday, April 13, 2017 6:51 PM > > > To: Limonciello, Mario <mario_limoncie...@dell.com> > > > Cc: pali.ro...@gmail.com; r...@rjwysocki.net; len.br...@intel.com; > > > corentin.ch...@gmail.com; l...@kernel.org; > andriy.shevche...@linux.intel.com; > > > linux-kernel@vger.kernel.org; platform-driver-...@vger.kernel.org; linux- > > > p...@vger.kernel.org > > > Subject: Re: RFC: WMI Enhancements > > > > > > On Thu, Apr 13, 2017 at 08:38:28PM +0000, mario.limoncie...@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.
