Re: [PATCH] video: backlight: Remove backlight sysfs uevent

[Henrique de Moraes Holschuh]

On Wed, 20 Nov 2013, Matthew Garrett wrote:
> On Mon, 2013-11-11 at 22:56 -0200, Henrique de Moraes Holschuh wrote:
> > On Tue, 12 Nov 2013, Jingoo Han wrote:
> > > 'thinkpad_acpi.c' uses the 'BACKLIGHT_UPDATE_SYSFS'.
> > > Henrique, can we remove it?
> > 
> > Can't you fix this by rate-limiting, or otherwise adding an attribute that
> > backlight devices should set when they need to supress change events?
> 
> It looks like this is just to force synchronisation to sysfs when using
> the /proc interface? In which case we should probably just kill
> the /proc interface.

Well, we can remove the thinkpad-acpi /proc interface as far as I'm
concerned, and that would do away with the use of BACKLIGHT_UPDATE_SYSFS by
thinkpad-acpi.  It is a major userspace ABI break, but removing everything
under /proc/acpi is one of the very few ABI breaks we actually have the
green light to do.

However, the patchset is not about this.

With this patchset applied, as far as I can tell anything that used to be
uevent-driven by the backlight class will break: when a process changes the
backlight using sysfs, other processes will not be notified of the change
anymore.  This patchset seems to break backlight uevent support in such a
way that basically renders the entire thing useless and you might as well
just remove uevent support entirely.

It is also an userspace ABI break, which we do not do lightly.

So, as far as I'm concerned, this patchset should be rejected in its present
form.  IMO, either one that preserves BACKLIGHT_UPDATE_SYSFS and fixes the
urgent issue, or one that removes uevent support entirely from the backlight
class should be proposed instead.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/