lkml.org 
[lkml]   [2017]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: WMI and Kernel:User interface
On Tue, Jun 13, 2017 at 06:52:47PM +0200, Greg Kroah-Hartman wrote:
> > As a concrete example, Dell has specifically made the request that we
> > work on a solution that doesn't require them to come back to the kernel
> > community each time they add a WMI GUID to their BIOS. They would like
> > to see those GUIDs automatically exposed.
>
> What do you mean exactly by "exposed"? What do they do with these? Why

By exposed I meant: the chardev for the WMI GUID is created

The idea being the kernel maps WMI GUIDs to chardevs and shepherds the
userspace calls through to the ACPI method evaluation and back. But the
kernel wmi driver doesn't, in general, have specific knowledge of the
methods or input and output formats.

The existing drivers being the exception to "specific knowledge", and
the cause of all this filter/proxy discussion. I think we have enough
that we can put together an initial patch series, and then discuss it
there.

> isn't the Dell pre-install team sending patches for this like the
> Windows preinstall team is doing for their hacked-to-hell copy of
> Windows? :)
>
> Do you have an example patch of something that was needed to get a Dell
> laptop working for a new device id that didn't work this way?

Per Mario's comment, it sounds like they are and it does work this way.
It takes 8 weeks, and they don't see a reason to go through this for WMI
GUIDs.

--
Darren Hart
VMware Open Source Technology Center

\
 
 \ /
  Last update: 2017-06-13 19:07    [W:1.820 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site