Calling kobject_uevent directly

Calling kobject_uevent directly

[Tom]

For devices with attributes that may change, is it "correct" to call
kobject_uevent directly with KOBJ_CHANGE in order to notify userspace?

(This appears to be the behavior used in the drivers/mmc/host/omap.c driver)

The KOBJ_ADD and KOBJ_REMOVE actions have comments saying "exclusive
to core". Is this policy or is there a technical reason?

-------------------------------------------------------------------------
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

Re: Calling kobject_uevent directly

[Greg KH]

On Tue, Nov 06, 2007 at 09:52:36PM -0800, Tom wrote:
> For devices with attributes that may change, is it "correct" to call
> kobject_uevent directly with KOBJ_CHANGE in order to notify userspace?

Yes.  And what attribute do you want to do this for?

> (This appears to be the behavior used in the drivers/mmc/host/omap.c driver)
> 
> The KOBJ_ADD and KOBJ_REMOVE actions have comments saying "exclusive
> to core". Is this policy or is there a technical reason?

Both.  lots of userspace stuff happens when these events are sent, so
don't be sending them unless you really think you know what you are
doing.  And even then, please run the kernel patch by me and Kay to
ensure that nothing bad will happen.

Do you have a reason why you would want to do this?

thanks,

greg k-h

-------------------------------------------------------------------------
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

Re: Calling kobject_uevent directly

[Kay Sievers]

On Nov 7, 2007 7:53 AM, Greg KH <greg@kroah.com> wrote:
> On Tue, Nov 06, 2007 at 09:52:36PM -0800, Tom wrote:
> > For devices with attributes that may change, is it "correct" to call
> > kobject_uevent directly with KOBJ_CHANGE in order to notify userspace?
>
> Yes.  And what attribute do you want to do this for?

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()

> > (This appears to be the behavior used in the drivers/mmc/host/omap.c driver)
> >
> > The KOBJ_ADD and KOBJ_REMOVE actions have comments saying "exclusive
> > to core". Is this policy or is there a technical reason?
>
> Both.  lots of userspace stuff happens when these events are sent, so
> don't be sending them unless you really think you know what you are
> doing.

The actions "add" and "remove" are sent by the core when devices are
created or get
removed, it would be wrong to send "add" events for device which are
already there,
just to let userspace know that something has changed. It might break valid
assumptions.

> And even then, please run the kernel patch by me and Kay to
> ensure that nothing bad will happen.
>
> Do you have a reason why you would want to do this?

Thanks,
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

Re: Calling kobject_uevent directly

[Tom]

> 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?)

-------------------------------------------------------------------------
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

Re: Calling kobject_uevent directly

[Kay Sievers]

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

Re: Calling kobject_uevent directly

[Tom]

On Nov 7, 2007 4:07 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
> 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.

I'm working on an embedded device, so to me the speed would be useful
if it is more than a trivial speedup.

-------------------------------------------------------------------------
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