Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1638442 > unrolled thread

WMI and Kernel:User interface

Back to article view | Back to linux.kernel

Contents

  WMI and Kernel:User interface Darren Hart <dvhart@infradead.org> - 2017-05-10 01:20 +0200
    Re: WMI and Kernel:User interface Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-10 07:20 +0200
      Re: WMI and Kernel:User interface Darren Hart <dvhart@infradead.org> - 2017-05-10 08:20 +0200
        RE: WMI and Kernel:User interface <Mario.Limonciello@dell.com> - 2017-05-11 00:10 +0200
          Re: WMI and Kernel:User interface Darren Hart <dvhart@infradead.org> - 2017-05-11 00:20 +0200
          Re: WMI and Kernel:User interface Andy Lutomirski <luto@kernel.org> - 2017-05-11 01:00 +0200
            Re: WMI and Kernel:User interface Darren Hart <dvhart@infradead.org> - 2017-05-11 01:30 +0200
          Re: WMI and Kernel:User interface Darren Hart <dvhart@infradead.org> - 2017-05-11 01:30 +0200

#1638442 — WMI and Kernel:User interface

Linus and Greg,

We are in the process of redesigning the Windows Management Instrumentation
(WMI) [1] system in the kernel. WMI is the Microsoft implementation of Web-Based
Enterprise Management (WBEM). We are looking to provide WMI access to userspace,
while allowing the kernel to filter requests that conflict with its own usage.
We'd like your take on how this approach relates to our commitment to not break
userspace.

For this discussion, we are specifically referring to ACPI PNP0C14 WMI
devices, consisting of a GUID and a set of methods and events, as well as a
precompiled intermediate description of the methods and arguments (MOF). Exposed
to userspace, these methods provide for BIOS interaction and are used for system
management as well as LEDs, hot keys, radio switches, etc. There is vendor
interest in achieving feature parity with Windows by exposing WMI methods to
userspace for system management.

While it appears WMI intended to be accessed from userspace, we have
made use of it in the kernel to support various laptop features by connecting
the WMI methods to other subsystems, notably input, leds, and rfkill [2]. The
challenge is continuing to use WMI for these platform features, while allowing
userspace to use it for system management tasks. Unfortunately, the WMI methods
are not guaranteed to be split up along granular functional lines, and we will
certainly face situations where the same GUID::METHOD_ID will be needed for a
kernel feature (say LED support) as well as a system management task.

To address this, I have proposed [3] that exporting WMI be opt-in, only done at
the request of and in collaboration with a vendor, with the kernel platform
driver given the opportunity to filter requests. This filtering would need to be
at the method and argument inspection level, such as checking for specific bits
in the input buffer, and rejecting the request if they conflict with an in
kernel usage (that's worst case, in some cases just GUID or method ID could be
sufficient).

Because the kernel and the platform drivers are under continual development, and
new systems appear regularly, we will encounter necessary changes to the
platform driver WMI request filters. These changes could be considered a change
to the kernel provided WMI interface to userspace. For example, we could
regularly accept a call to $GUID::$METHOD_ID with bit 4 of the buffer set, and
later deny the call when we determine it interferes with kernel usage.

In your view, is it acceptable to provide a chardev interface, for example,
exposing WMI methods to userspace, with the understanding that the kernel may
choose to filter certain requests which conflict with its own use? And that this
filtering may change as new features are added to the platform drivers?

1. https://msdn.microsoft.com/en-us/library/aa384642(v=vs.85).aspx
2. https://lwn.net/Articles/391230/
3. https://lists.gt.net/linux/kernel/2671309/?page=1;

-- 
Darren Hart
VMware Open Source Technology Center

[toc] | [next] | [standalone]

#1638563

On Tue, May 09, 2017 at 04:16:39PM -0700, Darren Hart wrote:
> Linus and Greg,
> 
> We are in the process of redesigning the Windows Management Instrumentation
> (WMI) [1] system in the kernel. WMI is the Microsoft implementation of Web-Based
> Enterprise Management (WBEM). We are looking to provide WMI access to userspace,
> while allowing the kernel to filter requests that conflict with its own usage.
> We'd like your take on how this approach relates to our commitment to not break
> userspace.
> 
> For this discussion, we are specifically referring to ACPI PNP0C14 WMI
> devices, consisting of a GUID and a set of methods and events, as well as a
> precompiled intermediate description of the methods and arguments (MOF). Exposed
> to userspace, these methods provide for BIOS interaction and are used for system
> management as well as LEDs, hot keys, radio switches, etc. There is vendor
> interest in achieving feature parity with Windows by exposing WMI methods to
> userspace for system management.
> 
> While it appears WMI intended to be accessed from userspace, we have
> made use of it in the kernel to support various laptop features by connecting
> the WMI methods to other subsystems, notably input, leds, and rfkill [2]. The
> challenge is continuing to use WMI for these platform features, while allowing
> userspace to use it for system management tasks. Unfortunately, the WMI methods
> are not guaranteed to be split up along granular functional lines, and we will
> certainly face situations where the same GUID::METHOD_ID will be needed for a
> kernel feature (say LED support) as well as a system management task.
> 
> To address this, I have proposed [3] that exporting WMI be opt-in, only done at
> the request of and in collaboration with a vendor, with the kernel platform
> driver given the opportunity to filter requests. This filtering would need to be
> at the method and argument inspection level, such as checking for specific bits
> in the input buffer, and rejecting the request if they conflict with an in
> kernel usage (that's worst case, in some cases just GUID or method ID could be
> sufficient).
> 
> Because the kernel and the platform drivers are under continual development, and
> new systems appear regularly, we will encounter necessary changes to the
> platform driver WMI request filters. These changes could be considered a change
> to the kernel provided WMI interface to userspace. For example, we could
> regularly accept a call to $GUID::$METHOD_ID with bit 4 of the buffer set, and
> later deny the call when we determine it interferes with kernel usage.
> 
> In your view, is it acceptable to provide a chardev interface, for example,
> exposing WMI methods to userspace, with the understanding that the kernel may
> choose to filter certain requests which conflict with its own use? And that this
> filtering may change as new features are added to the platform drivers?

So, for example, if a new driver for a "brightness key" were added to
the kernel, all of a sudden the "raw" access to the wmi data through the
chardev would filtered away by the kernel and not seen by userspace?

Why would you want to do that?  What's wrong with providing "raw" access
through a chardev, and the current in-kernel access as well at the same
time?

I don't really understand what would "break" over time here.

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1638578

On Wed, May 10, 2017 at 07:13:41AM +0200, Greg Kroah-Hartman wrote:
> On Tue, May 09, 2017 at 04:16:39PM -0700, Darren Hart wrote:
> > Linus and Greg,
> > 
> > We are in the process of redesigning the Windows Management Instrumentation
> > (WMI) [1] system in the kernel. WMI is the Microsoft implementation of Web-Based
> > Enterprise Management (WBEM). We are looking to provide WMI access to userspace,
> > while allowing the kernel to filter requests that conflict with its own usage.
> > We'd like your take on how this approach relates to our commitment to not break
> > userspace.
> > 
> > For this discussion, we are specifically referring to ACPI PNP0C14 WMI
> > devices, consisting of a GUID and a set of methods and events, as well as a
> > precompiled intermediate description of the methods and arguments (MOF). Exposed
> > to userspace, these methods provide for BIOS interaction and are used for system
> > management as well as LEDs, hot keys, radio switches, etc. There is vendor
> > interest in achieving feature parity with Windows by exposing WMI methods to
> > userspace for system management.
> > 
> > While it appears WMI intended to be accessed from userspace, we have
> > made use of it in the kernel to support various laptop features by connecting
> > the WMI methods to other subsystems, notably input, leds, and rfkill [2]. The
> > challenge is continuing to use WMI for these platform features, while allowing
> > userspace to use it for system management tasks. Unfortunately, the WMI methods
> > are not guaranteed to be split up along granular functional lines, and we will
> > certainly face situations where the same GUID::METHOD_ID will be needed for a
> > kernel feature (say LED support) as well as a system management task.
> > 
> > To address this, I have proposed [3] that exporting WMI be opt-in, only done at
> > the request of and in collaboration with a vendor, with the kernel platform
> > driver given the opportunity to filter requests. This filtering would need to be
> > at the method and argument inspection level, such as checking for specific bits
> > in the input buffer, and rejecting the request if they conflict with an in
> > kernel usage (that's worst case, in some cases just GUID or method ID could be
> > sufficient).
> > 
> > Because the kernel and the platform drivers are under continual development, and
> > new systems appear regularly, we will encounter necessary changes to the
> > platform driver WMI request filters. These changes could be considered a change
> > to the kernel provided WMI interface to userspace. For example, we could
> > regularly accept a call to $GUID::$METHOD_ID with bit 4 of the buffer set, and
> > later deny the call when we determine it interferes with kernel usage.
> > 
> > In your view, is it acceptable to provide a chardev interface, for example,
> > exposing WMI methods to userspace, with the understanding that the kernel may
> > choose to filter certain requests which conflict with its own use? And that this
> > filtering may change as new features are added to the platform drivers?
> 
> So, for example, if a new driver for a "brightness key" were added to
> the kernel, all of a sudden the "raw" access to the wmi data through the
> chardev would filtered away by the kernel and not seen by userspace?
> 

Pali provided some detail in the rather lengthy thread I linked to [3], but the
summary is that there is nothing to encourage vendors to separate out
functionality into separate method ids. Some do, the asus-wmi driver seems to
have a reasonable separation, others do a lot with a single method id.

In the scenario you mention, it could be that the brightness key shows up in a
new laptop. Because we've never seen it before, the kernel driver doesn't detect
it and send the input event. The clever user realizes they can write a userspace
program to deal with this [a] by writing a my-laptop-brightness-key-daemon which
also makes a WMI method call to affect the change in brightness in response to
the keypress.

Another user notices the dmesg is reporting "Unknown WMI Event" when they press
that key and send a patch to make the corresponding wmi call to affect the
brightness change (which depends on driver data to track the brightness value).
To avoid conflicting with userspace, they also blacklist the WMI_BRIGHTNESS_CMD
from being called by userspace.

Now the first user makes a call to set the brightness, and receives an error
code instead of a successful response. Their program no longer works - although
with a current kernel, their brightness key would.

I glossed over a few things there, but the description isn't too far off from a
plausible scenario.

> Why would you want to do that?  What's wrong with providing "raw" access
> through a chardev, and the current in-kernel access as well at the same
> time?
> 
> I don't really understand what would "break" over time here.

Like the scenario above, if the behavior has state, if userspace and the kernel
attempt to control it, neither will have an accurate state representation.

We could allow both and if things start not working, the user would have to
choose between the kernel driver and the userspace management application. This
was the scenario Pali was particularly keen to avoid.

That said, to date I haven't come across anything that states there can only be
one userspace application accessing WMI at any given time. It should be
straightforward to serialize WMI calls such that they cannot "cross the
streams".

> 
> thanks,
> 
> greg k-h
> 

a. This is perhaps a contrived scenario since hotkeys generate events, and as
far as I understand it, there is no interest in exporting events to userspace,
just the methods.

-- 
Darren Hart
VMware Open Source Technology Center

[toc] | [prev] | [next] | [standalone]

#1639090

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@infradead.org]
> Sent: Wednesday, May 10, 2017 1:12 AM
> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>; Limonciello, Mario
> <Mario_Limonciello@Dell.com>; Pali Rohár <pali.rohar@gmail.com>; Andy
> Shevchenko <andriy.shevchenko@linux.intel.com>; Rafael Wysocki
> <rjw@rjwysocki.net>; Andy Lutomirski <luto@amacapital.net>; LKML <linux-
> kernel@vger.kernel.org>; platform-driver-x86@vger.kernel.org
> Subject: Re: WMI and Kernel:User interface
> 
> On Wed, May 10, 2017 at 07:13:41AM +0200, Greg Kroah-Hartman wrote:
> > On Tue, May 09, 2017 at 04:16:39PM -0700, Darren Hart wrote:
> > > Linus and Greg,
> > >
> > > We are in the process of redesigning the Windows Management
> Instrumentation
> > > (WMI) [1] system in the kernel. WMI is the Microsoft implementation of Web-
> Based
> > > Enterprise Management (WBEM). We are looking to provide WMI access to
> userspace,
> > > while allowing the kernel to filter requests that conflict with its own usage.
> > > We'd like your take on how this approach relates to our commitment to not
> break
> > > userspace.
> > >
> > > For this discussion, we are specifically referring to ACPI PNP0C14 WMI
> > > devices, consisting of a GUID and a set of methods and events, as well as a
> > > precompiled intermediate description of the methods and arguments (MOF).
> Exposed
> > > to userspace, these methods provide for BIOS interaction and are used for
> system
> > > management as well as LEDs, hot keys, radio switches, etc. There is vendor
> > > interest in achieving feature parity with Windows by exposing WMI methods to
> > > userspace for system management.
> > >
> > > While it appears WMI intended to be accessed from userspace, we have
> > > made use of it in the kernel to support various laptop features by connecting
> > > the WMI methods to other subsystems, notably input, leds, and rfkill [2]. The
> > > challenge is continuing to use WMI for these platform features, while allowing
> > > userspace to use it for system management tasks. Unfortunately, the WMI
> methods
> > > are not guaranteed to be split up along granular functional lines, and we will
> > > certainly face situations where the same GUID::METHOD_ID will be needed for
> a
> > > kernel feature (say LED support) as well as a system management task.
> > >
> > > To address this, I have proposed [3] that exporting WMI be opt-in, only done at
> > > the request of and in collaboration with a vendor, with the kernel platform
> > > driver given the opportunity to filter requests. This filtering would need to be
> > > at the method and argument inspection level, such as checking for specific bits
> > > in the input buffer, and rejecting the request if they conflict with an in
> > > kernel usage (that's worst case, in some cases just GUID or method ID could be
> > > sufficient).
> > >
> > > Because the kernel and the platform drivers are under continual development,
> and
> > > new systems appear regularly, we will encounter necessary changes to the
> > > platform driver WMI request filters. These changes could be considered a
> change
> > > to the kernel provided WMI interface to userspace. For example, we could
> > > regularly accept a call to $GUID::$METHOD_ID with bit 4 of the buffer set, and
> > > later deny the call when we determine it interferes with kernel usage.
> > >
> > > In your view, is it acceptable to provide a chardev interface, for example,
> > > exposing WMI methods to userspace, with the understanding that the kernel
> may
> > > choose to filter certain requests which conflict with its own use? And that this
> > > filtering may change as new features are added to the platform drivers?
> >
> > So, for example, if a new driver for a "brightness key" were added to
> > the kernel, all of a sudden the "raw" access to the wmi data through the
> > chardev would filtered away by the kernel and not seen by userspace?
> >
> 
> Pali provided some detail in the rather lengthy thread I linked to [3], but the
> summary is that there is nothing to encourage vendors to separate out
> functionality into separate method ids. Some do, the asus-wmi driver seems to
> have a reasonable separation, others do a lot with a single method id.
> 
> In the scenario you mention, it could be that the brightness key shows up in a
> new laptop. Because we've never seen it before, the kernel driver doesn't detect
> it and send the input event. The clever user realizes they can write a userspace
> program to deal with this [a] by writing a my-laptop-brightness-key-daemon which
> also makes a WMI method call to affect the change in brightness in response to
> the keypress.
> 
> Another user notices the dmesg is reporting "Unknown WMI Event" when they
> press
> that key and send a patch to make the corresponding wmi call to affect the
> brightness change (which depends on driver data to track the brightness value).
> To avoid conflicting with userspace, they also blacklist the WMI_BRIGHTNESS_CMD
> from being called by userspace.
> 
> Now the first user makes a call to set the brightness, and receives an error
> code instead of a successful response. Their program no longer works - although
> with a current kernel, their brightness key would.
> 
> I glossed over a few things there, but the description isn't too far off from a
> plausible scenario.
> 
> > Why would you want to do that?  What's wrong with providing "raw" access
> > through a chardev, and the current in-kernel access as well at the same
> > time?
> >
> > I don't really understand what would "break" over time here.
> 
> Like the scenario above, if the behavior has state, if userspace and the kernel
> attempt to control it, neither will have an accurate state representation.
> 
> We could allow both and if things start not working, the user would have to
> choose between the kernel driver and the userspace management application. This
> was the scenario Pali was particularly keen to avoid.
> 
> That said, to date I haven't come across anything that states there can only be
> one userspace application accessing WMI at any given time. It should be
> straightforward to serialize WMI calls such that they cannot "cross the
> streams".
> 
> >
> > thanks,
> >
> > greg k-h
> >
> 
> a. This is perhaps a contrived scenario since hotkeys generate events, and as
> far as I understand it, there is no interest in exporting events to userspace,
> just the methods.
> 
> --
> Darren Hart
> VMware Open Source Technology Center

This above discussion is confusing because it's referring specifically to "WMI events".
related to brightness keypresses that don't make sense to go to userspace.

The more interesting (and potentially problematic) area is things that read and write
data using ASL methods.

So here's a "more" realistic scenario:

OEM has support through a WMI function to control keyboard backlight timeouts
and intensity.  That same WMI function also can support turning on/off an individual
USB port.  Backlight timeouts are done by setting the first argument to "1" and USB
port control is done by setting first argument to "2".

Some userspace app is developed that can control both of these functions through
the chardev.  Later an enterprising young kernel developer realizes that backlight 
control should be done through a platform driver instead.

They write a platform driver to do it, and add a filter to block "1" arguments from
userspace.  Now if the userspace app tries to call the chardev with the "1" argument
some error code is returned indicating this request is not supported.

The result is the userspace app broke, but it broke because the kernel is supporting
the method in a much smarter and more scalable way.

[toc] | [prev] | [next] | [standalone]

#1639091

On Wed, May 10, 2017 at 10:02:46PM +0000, Mario.Limonciello@dell.com wrote:
> > -----Original Message-----
> > From: Darren Hart [mailto:dvhart@infradead.org]
> > Sent: Wednesday, May 10, 2017 1:12 AM
> > To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Linus Torvalds <torvalds@linux-foundation.org>; Limonciello, Mario
> > <Mario_Limonciello@Dell.com>; Pali Rohár <pali.rohar@gmail.com>; Andy
> > Shevchenko <andriy.shevchenko@linux.intel.com>; Rafael Wysocki
> > <rjw@rjwysocki.net>; Andy Lutomirski <luto@amacapital.net>; LKML <linux-
> > kernel@vger.kernel.org>; platform-driver-x86@vger.kernel.org
> > Subject: Re: WMI and Kernel:User interface
> > 
> > On Wed, May 10, 2017 at 07:13:41AM +0200, Greg Kroah-Hartman wrote:
> > > On Tue, May 09, 2017 at 04:16:39PM -0700, Darren Hart wrote:
> > > > Linus and Greg,
> > > >
> > > > We are in the process of redesigning the Windows Management
> > Instrumentation
> > > > (WMI) [1] system in the kernel. WMI is the Microsoft implementation of Web-
> > Based
> > > > Enterprise Management (WBEM). We are looking to provide WMI access to
> > userspace,
> > > > while allowing the kernel to filter requests that conflict with its own usage.
> > > > We'd like your take on how this approach relates to our commitment to not
> > break
> > > > userspace.
> > > >
> > > > For this discussion, we are specifically referring to ACPI PNP0C14 WMI
> > > > devices, consisting of a GUID and a set of methods and events, as well as a
> > > > precompiled intermediate description of the methods and arguments (MOF).
> > Exposed
> > > > to userspace, these methods provide for BIOS interaction and are used for
> > system
> > > > management as well as LEDs, hot keys, radio switches, etc. There is vendor
> > > > interest in achieving feature parity with Windows by exposing WMI methods to
> > > > userspace for system management.
> > > >
> > > > While it appears WMI intended to be accessed from userspace, we have
> > > > made use of it in the kernel to support various laptop features by connecting
> > > > the WMI methods to other subsystems, notably input, leds, and rfkill [2]. The
> > > > challenge is continuing to use WMI for these platform features, while allowing
> > > > userspace to use it for system management tasks. Unfortunately, the WMI
> > methods
> > > > are not guaranteed to be split up along granular functional lines, and we will
> > > > certainly face situations where the same GUID::METHOD_ID will be needed for
> > a
> > > > kernel feature (say LED support) as well as a system management task.
> > > >
> > > > To address this, I have proposed [3] that exporting WMI be opt-in, only done at
> > > > the request of and in collaboration with a vendor, with the kernel platform
> > > > driver given the opportunity to filter requests. This filtering would need to be
> > > > at the method and argument inspection level, such as checking for specific bits
> > > > in the input buffer, and rejecting the request if they conflict with an in
> > > > kernel usage (that's worst case, in some cases just GUID or method ID could be
> > > > sufficient).
> > > >
> > > > Because the kernel and the platform drivers are under continual development,
> > and
> > > > new systems appear regularly, we will encounter necessary changes to the
> > > > platform driver WMI request filters. These changes could be considered a
> > change
> > > > to the kernel provided WMI interface to userspace. For example, we could
> > > > regularly accept a call to $GUID::$METHOD_ID with bit 4 of the buffer set, and
> > > > later deny the call when we determine it interferes with kernel usage.
> > > >
> > > > In your view, is it acceptable to provide a chardev interface, for example,
> > > > exposing WMI methods to userspace, with the understanding that the kernel
> > may
> > > > choose to filter certain requests which conflict with its own use? And that this
> > > > filtering may change as new features are added to the platform drivers?
> > >
> > > So, for example, if a new driver for a "brightness key" were added to
> > > the kernel, all of a sudden the "raw" access to the wmi data through the
> > > chardev would filtered away by the kernel and not seen by userspace?
> > >
> > 
> > Pali provided some detail in the rather lengthy thread I linked to [3], but the
> > summary is that there is nothing to encourage vendors to separate out
> > functionality into separate method ids. Some do, the asus-wmi driver seems to
> > have a reasonable separation, others do a lot with a single method id.
> > 
> > In the scenario you mention, it could be that the brightness key shows up in a
> > new laptop. Because we've never seen it before, the kernel driver doesn't detect
> > it and send the input event. The clever user realizes they can write a userspace
> > program to deal with this [a] by writing a my-laptop-brightness-key-daemon which
> > also makes a WMI method call to affect the change in brightness in response to
> > the keypress.
> > 
> > Another user notices the dmesg is reporting "Unknown WMI Event" when they
> > press
> > that key and send a patch to make the corresponding wmi call to affect the
> > brightness change (which depends on driver data to track the brightness value).
> > To avoid conflicting with userspace, they also blacklist the WMI_BRIGHTNESS_CMD
> > from being called by userspace.
> > 
> > Now the first user makes a call to set the brightness, and receives an error
> > code instead of a successful response. Their program no longer works - although
> > with a current kernel, their brightness key would.
> > 
> > I glossed over a few things there, but the description isn't too far off from a
> > plausible scenario.
> > 
> > > Why would you want to do that?  What's wrong with providing "raw" access
> > > through a chardev, and the current in-kernel access as well at the same
> > > time?
> > >
> > > I don't really understand what would "break" over time here.
> > 
> > Like the scenario above, if the behavior has state, if userspace and the kernel
> > attempt to control it, neither will have an accurate state representation.
> > 
> > We could allow both and if things start not working, the user would have to
> > choose between the kernel driver and the userspace management application. This
> > was the scenario Pali was particularly keen to avoid.
> > 
> > That said, to date I haven't come across anything that states there can only be
> > one userspace application accessing WMI at any given time. It should be
> > straightforward to serialize WMI calls such that they cannot "cross the
> > streams".
> > 
> > >
> > > thanks,
> > >
> > > greg k-h
> > >
> > 
> > a. This is perhaps a contrived scenario since hotkeys generate events, and as
> > far as I understand it, there is no interest in exporting events to userspace,
> > just the methods.
> > 
> > --
> > Darren Hart
> > VMware Open Source Technology Center
> 
> This above discussion is confusing because it's referring specifically to "WMI events".
> related to brightness keypresses that don't make sense to go to userspace.
> 
> The more interesting (and potentially problematic) area is things that read and write
> data using ASL methods.
> 
> So here's a "more" realistic scenario:
> 
> OEM has support through a WMI function to control keyboard backlight timeouts
> and intensity.  That same WMI function also can support turning on/off an individual
> USB port.  Backlight timeouts are done by setting the first argument to "1" and USB
> port control is done by setting first argument to "2".
> 
> Some userspace app is developed that can control both of these functions through
> the chardev.  Later an enterprising young kernel developer realizes that backlight 
> control should be done through a platform driver instead.
> 
> They write a platform driver to do it, and add a filter to block "1" arguments from
> userspace.  Now if the userspace app tries to call the chardev with the "1" argument
> some error code is returned indicating this request is not supported.
> 
> The result is the userspace app broke, but it broke because the kernel is supporting
> the method in a much smarter and more scalable way.
> 

Thank you Mario, that's a much better example.

-- 
Darren Hart
VMware Open Source Technology Center

[toc] | [prev] | [next] | [standalone]

#1639097

On Wed, May 10, 2017 at 3:02 PM,  <Mario.Limonciello@dell.com> wrote:
> So here's a "more" realistic scenario:
>
> OEM has support through a WMI function to control keyboard backlight timeouts
> and intensity.  That same WMI function also can support turning on/off an individual
> USB port.  Backlight timeouts are done by setting the first argument to "1" and USB
> port control is done by setting first argument to "2".
>
> Some userspace app is developed that can control both of these functions through
> the chardev.  Later an enterprising young kernel developer realizes that backlight
> control should be done through a platform driver instead.
>
> They write a platform driver to do it, and add a filter to block "1" arguments from
> userspace.  Now if the userspace app tries to call the chardev with the "1" argument
> some error code is returned indicating this request is not supported.
>
> The result is the userspace app broke, but it broke because the kernel is supporting
> the method in a much smarter and more scalable way.

There's another possibility: the filter could intercept the "1"
argument and change the brightness.

FWIW, I think that almost anything the kernel did with a real WMI API
would be better than the ugly things that drivers like dcdbas allow.

--Andy

[toc] | [prev] | [next] | [standalone]

#1639107

On Wed, May 10, 2017 at 03:50:44PM -0700, Andy Lutomirski wrote:
> On Wed, May 10, 2017 at 3:02 PM,  <Mario.Limonciello@dell.com> wrote:
> > So here's a "more" realistic scenario:
> >
> > OEM has support through a WMI function to control keyboard backlight timeouts
> > and intensity.  That same WMI function also can support turning on/off an individual
> > USB port.  Backlight timeouts are done by setting the first argument to "1" and USB
> > port control is done by setting first argument to "2".
> >
> > Some userspace app is developed that can control both of these functions through
> > the chardev.  Later an enterprising young kernel developer realizes that backlight
> > control should be done through a platform driver instead.
> >
> > They write a platform driver to do it, and add a filter to block "1" arguments from
> > userspace.  Now if the userspace app tries to call the chardev with the "1" argument
> > some error code is returned indicating this request is not supported.
> >
> > The result is the userspace app broke, but it broke because the kernel is supporting
> > the method in a much smarter and more scalable way.
> 
> There's another possibility: the filter could intercept the "1"
> argument and change the brightness.

That would be a good way to deal with regressions if we encounter them after
filtering a call. In general we would want to filter as few calls as possible,
and only if there is a detrimental effect for both userspace and the kernel
using the call. e.g. if the backlight call is stateless, then there is no
problem with both userspace and the kernel using it.

> FWIW, I think that almost anything the kernel did with a real WMI API
> would be better than the ugly things that drivers like dcdbas allow.
> 
> --Andy
> 

-- 
Darren Hart
VMware Open Source Technology Center

[toc] | [prev] | [next] | [standalone]

#1639109

On Wed, May 10, 2017 at 10:02:46PM +0000, Mario.Limonciello@dell.com wrote:
> This above discussion is confusing because it's referring specifically to "WMI events".
> related to brightness keypresses that don't make sense to go to userspace.

Let's elaborate on this point. Why are events not interesting to user space?

I don't think it would be too problematic to create a chardev for an Event GUID,
give platform drivers first chance to handle an event, and pass it up to
userspace for exported GUIDs if the kernel doesn't consume the event.

-- 
Darren Hart
VMware Open Source Technology Center

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web