[systemd-devel] [RFC][PATCH] udev: add exclusive event filter

[Kay Sievers]

On Mon, Nov 11, 2013 at 3:13 PM, Kyungmin Park <kmpark at infradead.org> wrote:
> On Mon, Nov 11, 2013 at 10:43 PM, Kay Sievers <kay at vrfy.org> wrote:

>>> I want to skip this kind of events just after retrieving from netlink
>>> without worker fork.
>>> This patch will filter-out(I could not find suitable vocabulary because
>>> of we already using "filter".) subsystem:devtype events what be listed
>>> in udev.conf. If we want to skip whole of subsystem then subsystem can
>>> only be specified.
>>
>> Please fix your kernel, driver, subsystem instead. Uevents were never
>> meant to carry higher-frequent events, it's justy not what they should
>> be used for.
>
> Here's real use cases for brightness.

Here is just the result of a completely misguided use of uevents. :)

> now most mobile phone has ambient Light Sensors and it changes
> brightness according lux.
> it means it changes backlight brightness by just writing backlight subsystem.
> in backlight subsystem, after writing sysfs node, it generates uevent.

Which is nothing but a terribly broken driver behavior. Using uevents
for such changes makes zero sense, the kernel should be fixed instead
to stop this nonsense.

> usually there's no user to use this backlight changes. but it forks
> udev worker threads and it takes about 5ms.
> the main problem is that it hurts other process activities.

Sure, I see the problem, but we do not want to work around such
brokenness in userspace.

> if you mean modify kernel driver, subsystem, we have to ignore below codes.
>
> Are there any other way to avoid these udev worker thread?

No, please fix the problem where it is caused.

Uevents are for the major, low-frequent, global device state-changes,
not for carrying-out any sort of measurement data. Subsystems which
need that should use other facilities like poll()-able sysfs file or
any other subscription-based, client-tracking interface which does not
cause overhead if it isn't used. Uevents are not the right thing to
use here, and upstream udev should not paper-over broken kernel
subsystems.

Thanks,
Kay