Re: WMI and Kernel:User interface

[Darren Hart <dvhart@infradead.org>]

On Tue, Jun 13, 2017 at 02:07:41PM +0200, Pali Rohár wrote:
> On Tuesday 13 June 2017 00:05:35 Christoph Hellwig wrote:
> > On Mon, Jun 12, 2017 at 06:24:35PM -0700, Darren Hart wrote:
> > > This is a big topic for sure. Speed and scale of platform enabling is something
> > > I would like to see us support better. The barrier to entry to kernel
> > > changes is high, especially for trivial things, like adding IDs, GUIDs, etc.
> > > which would ideally, IMHO, be in the hands of the OEMs.
> > 
> > It's not.  It's a trivial patch, and you cover all Linux users.  Very
> > much unlike say the windows world where you are stuck with installing
> > a vendor specific set of drivers forever.
> 
> Yes, adding new GUID is same hard as adding new PCI ID or USB ID. It is
> really trivial patch.


See my response to Christoph - it's not the complexity of the patch, it's the
timeline. As Christoph points out, however, dynamic IDs may address this
concern.

> 
> In some cases filter function can be simple in some cases hard. I can
> image that usage of while listing, plus in some cases also filtering
> (when it would be relatively easy to implement).

See my response to Christoph - to address the concern of breaking userspace
later, if we consider this a proxy instead of a filter, we can make it
transparent to userspace and maintain kernel driver state. The driver can
register a wmi_method_proxy callback which can choose to proxy the method call
or not. If it does, it can update it's own state and perform the requested
action through it's own infrastructure, populate the out buffer and send it back
up to userspace. I would hope to see as few of these as possible, but they would
allow for protecting the kernel drivers while still enabling userspace usage of
WMI.

-- 
Darren Hart
VMware Open Source Technology Center