kobj_attribute and followup to earlier post

["Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx>]

  just to add a bit more to what i posted/asked earlier regarding
sysfs attributes and show()/store() routines, here's the declaration
of the very generic kobj_attribute from kobject.h:

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);
};

  note first that the show/store routines for kobj_attribute *do*
include an actual kobj_attribute pointer (as the second arg), so it's
possible to define a single pair of callback routines that handles a
number of kobject attributes, given that those routines can check and
distinguish between them.  but that's not always what happens.

  note first how sysfs.h supplies a couple macros that can make
defining attributes really convenient:

#define __ATTR(_name,_mode,_show,_store) { \
        .attr = {.name = __stringify(_name), .mode = _mode },   \
        .show   = _show,                                        \
        .store  = _store,                                       \
}

#define __ATTR_RO(_name) { \
        .attr   = { .name = __stringify(_name), .mode = 0444 }, \
        .show   = _name##_show,                                 \
}

 note how (interestingly), while the general __ATTR macro still allows
you to specify the show and store routines, the __ATTR_RO macro for
defining read-only attributes *forces* the show routine to be
constructed using the name of the attribute itself, which then forces
each attribute to need its own show routine, even if a number of them
could have shared the same callback.

  this happens in, for example, mm/ksm.c:

#define KSM_ATTR_RO(_name) \
        static struct kobj_attribute _name##_attr = __ATTR_RO(_name)
#define KSM_ATTR(_name) \
        static struct kobj_attribute _name##_attr = \
                __ATTR(_name, 0644, _name##_show, _name##_store)
... snip ...
KSM_ATTR(sleep_millisecs);
KSM_ATTR(pages_to_scan);
KSM_ATTR(run);
KSM_ATTR_RO(pages_shared);
KSM_ATTR_RO(pages_sharing);
KSM_ATTR_RO(pages_unshared);
KSM_ATTR_RO(pages_volatile);
KSM_ATTR_RO(full_scans);
... snip ...


  so all of those KSM_ATTR_RO-defined attributes are forced to have
separate show() routines, which is fine.

  another example is drivers/staging/speakup/kobjects.c, which also
combines the two approaches:

/*
 * Declare the attributes.
 */
static struct kobj_attribute keymap_attribute =
        __ATTR(keymap, ROOT_W, keymap_show, keymap_store);
static struct kobj_attribute silent_attribute =
        __ATTR(silent, USER_W, NULL, silent_store);
static struct kobj_attribute synth_attribute =
        __ATTR(synth, USER_RW, synth_show, synth_store);
static struct kobj_attribute synth_direct_attribute =
        __ATTR(synth_direct, USER_W, NULL, synth_direct_store);
static struct kobj_attribute version_attribute =
        __ATTR_RO(version);

static struct kobj_attribute delimiters_attribute =
        __ATTR(delimiters, USER_RW, punc_show, punc_store);
static struct kobj_attribute ex_num_attribute =
        __ATTR(ex_num, USER_RW, punc_show, punc_store);
static struct kobj_attribute punc_all_attribute =
        __ATTR(punc_all, USER_RW, punc_show, punc_store);
static struct kobj_attribute punc_most_attribute =
        __ATTR(punc_most, USER_RW, punc_show, punc_store);
static struct kobj_attribute punc_some_attribute =
        __ATTR(punc_some, USER_RW, punc_show, punc_store);
static struct kobj_attribute repeats_attribute =
        __ATTR(repeats, USER_RW, punc_show, punc_store);
... anip ...

  here, we have some attributes defined with distinct show/store
callbacks, while others are defined to *share* a pair of routines
(punc_show, punc_store), which uses the attribute name to determine
what to do.

  finally, at the top of that very source file, we read:

 * This code is based on kobject-example.c, which came with linux 2.6.x.

well, ok, except that i don't think samples/kobject/kobject-example.c
really drives home the variations of defining sysfs attributes.

  in any event, this still brings me back to my original curiosity --
why were *some* sysfs attribute show/store callbacks defined as
accepting an attribute pointer (allowing them to multiplex among
attributes) while others weren't?  was there some rationale for this?


rday

-- 

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

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

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies