lkml.org 
[lkml]   [2004]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] kernel sysfs events layer
    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
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:05    [W:0.021 / U:0.600 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site