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
