rationale for sysfs attr store/show accepting kobj_attribute?

[Robert P. J. Day]

  more just a curiosity than anything else, but i'm perusing the
kobject sample programs in the kernel source directory and in
kobject-example.c, there's one thing about which i'm a bit puzzled.

  the kernel header file sysfs.h defines the basic attribute structure
as:

struct attribute {
        const char              *name;
        mode_t                  mode;
#ifdef CONFIG_DEBUG_LOCK_ALLOC
        struct lock_class_key   *key;
        struct lock_class_key   skey;
#endif
};

in other words, simply the attribute name and mode.  no problem.

  however, the header file kobject.h defines a more informative
kobj_attribute structure thusly:

struct kobj_attribute {
        struct attribute attr;
        ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr,
                        char *buf);
        ssize_t (*store)(struct kobject *kobj, struct kobj_attribute *attr,
                         const char *buf, size_t count);
};

as you can see, it's just a regular sysfs attribute, bundled with the
respective show and store routines.

  what puzzles me is why those show() and store() routines are defined
as being passed the larger kobj_attribute structure, rather than the
simpler sysfs attribute structure.  it doesn't seem as if there's much
value in having the show() and store() callbacks getting those two
extra pieces of information.

  in fact, in the sample program kobject-example.c, in the more
general example, the callback routine needs to check the name of the
attribute to know how to process it properly so it has to use
"attr->attr.name" to access the field of the simpler "struct
attribute" anyway.

  long question short -- even though it's clearly an arbitrary
decision, was there some rationale for having those callback show()
and store() routines be passed a pointer to the larger attribute
structure containing the show() and store() routine addresses
themselves (in this case, kobj_attribute)?  or is everything those
callback routines might be interested in available in the simpler
"struct attribute"?

  and, of course, if one wanted to get the enclosing attribute
structure, there's always "container_of", but i'd just like to know if
there was a reason for the choice that was made.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================