Re: Calling kobject_uevent directly

[Kay Sievers <kay.sievers@vrfy.org>]

On Wed, 2007-11-07 at 15:37 -0800, Tom wrote:
> > Right, it's fine to send "change", you can also add additional keys to
> > the environment,
> > to make it easier for the possible consumer so determine what this
> > event is about. See:
> >   drivers/acpi/dock.c::dock_event()
> 
> Is there any advantage to sending the additional key directly with
> kobject_uevent_env() rather than just doing a kobject_uevent() call
> and using SYSFS{attribute}="some_value" in the udev rule? (e.g.,
> perhaps it's faster?)

There is no general rule, and it doesn't really matter for most of the
users. It is a bit faster, sure, but that's not interesting at all here,
and definitely not a reason to put stuff into the environment.

If you need to send an "atomic" event, you will need to carry the data
in the environment, because the sysfs file may be read some time after
the event is sent and may return a different value in the meantime.
Think of a series of error conditions that may happen, or similar, it's
not possible to stick that into a sysfs file, but they can be put into a
stream of events.
Sometimes it's useful to add a "subtype" of the event to the
environment, which doesn't directly match to a sysfs file.

On the other hand, environment values are a bit harder to debug, because
they are not easily available for test scripts and such, and matches on
special environment keys will not work, without running from the real
event.

So, if you don't have special requirements, the plain sysfs files and
ATTR{} matches should be fine.

Kay


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel