Re: [patch] kernel sysfs events layer

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

On Thu, Sep 02, 2004 at 05:02:46AM -0700, Daniel Stekloff wrote:
> On Thu, 2004-09-02 at 01:34, Greg KH wrote:
> > On Tue, Aug 31, 2004 at 06:05:24PM -0400, Robert Love wrote:
> > > +int send_kevent(enum kevent type, struct kset *kset,
> > > +		struct kobject *kobj, const char *signal);
> > 
> > Why is the kset needed?  We can determine that from the kobject.
> > 
> > How about changing this to:
> > 	int send_kevent(struct kobject *kobj, struct attribute *attr);
> > which just tells userspace that a specific attribute needs to be read,
> > as something "important" has changed.
> 
> 
> Do all events require an attribute? What about the "overheating"
> example? Would you need an attribute or would getting a "signal" for a
> specific kobj be enough? 

Hmm, both can be the case at the moment. We need to decide, if we want to
mandate the use of a sysfs attribute instead of the string value as the signal.

> Binding an attribute to an event would at least tell you the name of the
> attribute to check. Otherwise, how does an app know the name of the
> attribute that changed? Or am I missing something?

That's a valid point, right. If we don't use "verbs" as the signal string,
and know what we can expect from that particular kind of event, we don't
know which attribute has changed.


The remaining questions are:

o Do we want the multicast - "channels" for the events? It may be nice, to
  have it, if a application only interested in e.g. hotplug events, can get
  only the interesting events?

o What kind of signal do we need? A lazy string, a well defined set like
  ADD/REMOVE/CHANGE?
  Or can we get rid of the whole signal? But how can we distinguish between
  add and remove? Watching if the sysfs file comes or goes is not a option,
  I think.

Thanks,
Kay