[lkml]   [2004]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] kernel sysfs events layer
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);

Dig that?


Robert Love

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:05    [W:0.149 / U:1.536 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site