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
