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

[Kyungmin Park]

On Mon, Nov 11, 2013 at 10:43 PM, Kay Sievers <kay at vrfy.org> wrote:
> On Mon, Nov 11, 2013 at 8:12 AM, WaLyong Cho <walyong.cho at samsung.com> wrote:
>> Previously, ignore_device option had existed until udev 147. But that
>> was removed after below commit.
>>
>> cdae488a3fbca5a61b3f8ea0651730cfa2da9cb0
>>
>> remove "ignore_device"
>> There is no way to ignore an event these days. Libudev events can
>> not be suppressed. It only prevents RUN keys from being executed,
>> which results in an inconsistent behavior in current setups.
>>
>> http://cgit.freedesktop.org/systemd/systemd/commit/?id=cdae488a3fbca5a61b3f8ea0651730cfa2da9cb0
>>
>>
>> In mobile(maybe also embedded) world, power and memory management are
>> big issue. That can not be compromised. If there are no tasks who
>> receive such uevents from udev monitor(not kernel monitor) then the
>> uevents are useless. Each uevent will may cause each fork() if there is
>> no idle worker.
>>
>> In our system, there is a special daemon who directly linked with kernel
>> monitor. (That is similar with system server of android.) He receive
>> event data from kernel monitor. And some of events are only treated by
>> him. Especially, backlight and power_supply(battery) events are. In
>> every change state of LCD, backlight events were occurred. In desktop
>> environment, this event may be occurred one or twice per hour. (Sure, it
>> can configurable.) And, in every battery percentage changing,
>> power_supply events were happen. (I couldn't see this on my fedora when
>> using ac-power. I'm not sure it because of full charged stated.) Anyway,
>> both of them are more frequently happen in mobile world.
>> In our worst case, a uevent(a kind of thermistor) was happen each 10
>> second. If udev is in idle state, udev will fork to process that event.
>> After processing(may be 3 sec), the worker will be terminated. There are
>> no workers during 7 seconds. And worker will be forked again by the uevent.
>> Yeah, it is a terrible repetition of our system.
>>
>> 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.

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.

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.

if you mean modify kernel driver, subsystem, we have to ignore below codes.

Are there any other way to avoid these udev worker thread?

85 static void backlight_generate_event(struct backlight_device *bd,
86                                      enum backlight_update_reason reason)
87 {
88         char *envp[2];
89
90         switch (reason) {
91         case BACKLIGHT_UPDATE_SYSFS:
92                 envp[0] = "SOURCE=sysfs";
93                 break;
94         case BACKLIGHT_UPDATE_HOTKEY:
95                 envp[0] = "SOURCE=hotkey";
96                 break;
97         default:
98                 envp[0] = "SOURCE=unknown";
99                 break;
100         }
101         envp[1] = NULL;
102         kobject_uevent_env(&bd->dev.kobj, KOBJ_CHANGE, envp);
103         sysfs_notify(&bd->dev.kobj, NULL, "actual_brightness");
104 }

http://git.infradead.org/linux-2.6.git/blob/HEAD:/drivers/video/backlight/backlight.c

Thank you,
Kyungmin Park
>
> And udev is not meant to filter or suppress any events from the
> kernel, it's too late in the game, and people will only mis-use things
> here, to paper-over broken kernel drivers. Upstream udev better does
> not want to provide such a facility.
>
> Thanks,
> Kay
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel