Re: [patch] kernel sysfs events layer

[Kay Sievers]

On Thu, Sep 02, 2004 at 10:34:08AM +0200, 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.

I expect it's because:
  fill_kobj_path(struct kset *kset, struct kobject *kobj, char *path, int length)
  get_kobj_path_length(struct kset *kset, struct kobject *kobj)

and therefore the exported:
  kobject_get_path(struct kset *kset, struct kobject *kobj, int gfp_mask)

are all passing the kset. If they all are not needed, they can go too?

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

Hmm, in most cases this will work. But in mandates the creation of an
attribute instead of the lazy signal string. Yes, it would be nicer in
the long run and closer to the idea, that the whole event data should be
available through sysfs, but it may be hard to reach this in some subsystems.

> Will passing the attribute name be able to successfully handle the 
> "enum kevent" and "signal" combinations?

What should we do in the hotplug case? We may send a NULL attr for
the kset creation. But how can we distinguish between "add" and "remove"?
Just by looking if we find the sysfs dir? I'm not sure in this case.

Any ideas?

Thanks,
Kay
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/