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