On Mon, Nov 11, 2013 at 3:13 PM, Kyungmin Park <[email protected]> wrote: > On Mon, Nov 11, 2013 at 10:43 PM, Kay Sievers <[email protected]> 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
