lkml.org 
[lkml]   [2005]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2.6.12-rc4 1/12] (dynamic sysfs callbacks) update device attribute callbacks
    Hi Russell,

    > I missed commenting on this first time round. What is the purpose behind
    > this idea?

    My first post to LKML on the patch:
    http://lkml.org/lkml/2005/5/7/60

    The idea originated in the lm_sensors mailing list, so you might want
    to take a look at the lm_sensors archive is you are interested, in
    particular the following thread:

    http://archives.andrew.net.au/lm-sensors/msg31162.html

    > Currently, sysfs attributes are generally static structures which don't
    > require allocation, and are shared between all objects. I'm unable to
    > see what advantage adding this void pointer is supposed to give us,
    > other than having to dynamically allocate these structures if we want
    > to use them.

    This isn't changing, although there are cases where it is
    necessary/preferable to dynamically create the attributes (again see
    previous discussion). This patch helps both static and dynamically
    created attributes. The adm1026 example I posted to the mailing list
    earlier uses entirely static attributes still (and hence the need for
    the new macros my latest patch adds), and I expect most attributes
    will remain static.

    > What's more, I don't really see what adding this buys us - we already
    > have the pointer which is supposed to identify the object passed in.

    Using device_attribute as an example (most other derived sysfs
    attributes have near identical callbacks):

    struct device_attribute {
    struct attribute attr;
    ssize_t (*show)(struct device * dev, char * buf);
    ssize_t (*store)(struct device * dev, const char * buf, size_t count);
    };

    The only pointer passed in the present callbacks is the device
    structure, this doesn't help at all identify what attribute the
    callback is for when a device can have many attributes.

    > There's another question - how is the lifetime of the object pointed
    > to by this void pointer managed?

    Think of the pointer like the the driver_data pointer in struct device
    (http://lxr.linux.no/source/include/linux/device.h#L270), except
    instead of driver specific data pointer, this is attribute specific
    data pointer, and might not even be used (i.e. NULL). What the pointer
    points to should managed by whatever created that entity... I kind of
    like Greg's renaming of the void * to private for reasons along those
    lines. Your question about lifetime seems to imply that that entity
    must be dynamically allocated, but that is not necessarily so.

    Thanks,
    Yani
    -
    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-05-14 21:49    [W:4.606 / U:2.440 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site