[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170614043853.GE10146@kroah.com>
Date: Wed, 14 Jun 2017 06:38:53 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Darren Hart <dvhart@...radead.org>
Cc: Christoph Hellwig <hch@...radead.org>,
Pali Rohár <pali.rohar@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Mario Limonciello <mario_limonciello@...l.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Rafael Wysocki <rjw@...ysocki.net>,
Andy Lutomirski <luto@...capital.net>,
LKML <linux-kernel@...r.kernel.org>,
platform-driver-x86@...r.kernel.org
Subject: Re: WMI and Kernel:User interface
On Tue, Jun 13, 2017 at 10:07:19AM -0700, Darren Hart wrote:
> 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.
Hah, and those people who insist on "secure boot" are going to allow
userspace access to ACPI methods like this? Well, I guess as Windows
does it, it must be ok...
I'll shut up now and just wait for patches :)
thanks,
greg k-h
Powered by blists - more mailing lists