Re: WMI and Kernel:User interface

[Darren Hart <dvhart@infradead.org>]

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