On Fri, Jan 30, 2015 at 04:30:02AM -0800, Robert P. J. Day wrote:
i'll try this one more time, but much more concisely. so far, i've seen two different ways to create a kobject's attributes and register callback routines for them:
the first general way i've seen is in mm/ksm.c, where each attribute is enclosed in a surrounding kobj_attribute structure, which also contains references to *generic* show() and store() routines:
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); };
in mm/ksm.c file, each attribute is associated *directly* with a different show() and store() routine specific to that attribute. so my understanding is, when you try to access a ksm attribute file under /sys, the generic attribute object is *assumed* to be contained inside a kobj_attribute structure, so dereferencing to get to the show() and store() routine for that attribute is easy.
is that correct? that is, the way ksm.c creates and registers attributes means that it is assumed "kobj_attribute" structures will be used as containers for generic attributes?
the second way is in cpufreq.c, where the difference is that, rather than each attribute file being *directly* associated with its own pair of callback routines, a pair of *generic* show() and store() routines are defined:
static ssize_t show(struct kobject *kobj, struct attribute *attr, char *buf)
static ssize_t store(struct kobject *kobj, struct attribute *attr, const char *buf, size_t count)
and the way the attributes are registered in *that* source file:
static const struct sysfs_ops sysfs_ops = { .show = show, .store = store, };
static struct kobj_type ktype_cpufreq = { .sysfs_ops = &sysfs_ops, .default_attrs = default_attrs, .release = cpufreq_sysfs_release, };
means that, rather than dereferencing each generic attribute to an enclosing kobj_attribute, each attribute file reference is redirected to the *same* generic show() and store() callback associated with the ktype, at which point those two generic callbacks are responsible for dereferencing a generic attribute pointer to get to (in this case), the enclosing cpufreq-specific freq_attr structure.
i *think* i got it right this time. comments?
If I'm understanding correctly, this is describing the same thing. "Sometimes all that a developer wants is a way to create a simple directory in the sysfs hierarchy, and not have to mess with the whole complication of ksets, show and store functions, and other details. This is the one exception where a single kobject should be created." from: Documentation/kobject.txt