From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Thu, 08 Nov 2007 00:07:15 +0000 Subject: Re: Calling kobject_uevent directly Message-Id: <1194480435.2303.72.camel@lov.site> List-Id: References: <58b503a50711062152x3e3cedafxde62c964174a3e53@mail.gmail.com> In-Reply-To: <58b503a50711062152x3e3cedafxde62c964174a3e53@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.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