Re: [patch] kernel sysfs events layer

[Robert Love]

On Thu, 2004-09-02 at 10:34 +0200, Greg KH wrote:

> 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.
> 
> Will passing the attribute name be able to successfully handle the 
> "enum kevent" and "signal" combinations?

We can drop the kset if you say we never need it.  Why do all the kobj
get_path functions take a kset then?  That is what confused me.

We can also drop the "enum kevent" if we decide we don't want to take
advantage of the multicasting of the netlink socket.  The enum defines
what multicast group the netlink message is sent out in.  I actually
have been talking to Kay about ditching it, and we are trying to figure
out if we ever _need_ it.

So that is 2 for 2.  But ...

I don't dig replacing the signal string with an attribute.  I think it
will really limit what we can do - having the signal as a verb
describing the event is really important.  We might also not always have
an attribute.  Kay's points are all valid.

So what if we had

	int send_kevent(struct kobject *kobj, const char *signal);

Which was a way of notifying user-space of a change of "signal" on the
object "kobj" in sysfs.

If we ever wanted to send an attribute, we can do something like

	const char *signal;

	signal = attribute_to_string(attribute);
	send_kevent(kobj, signal);
	kfree(signal);

Dig that?

Best,

	Robert Love


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