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 ========================================================================