On Wed, May 10, 2017 at 3:02 PM, <mario.limoncie...@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
