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