From: rpjday@crashcourse.ca (Robert P. J. Day)
To: kernelnewbies@lists.kernelnewbies.org
Subject: what should be a simple question about sysfs attributes ...
Date: Fri, 30 Jan 2015 04:30:02 -0800 (PST) [thread overview]
Message-ID: <alpine.LFD.2.11.1501300415440.2741@localhost> (raw)
In-Reply-To: <alpine.LFD.2.11.1501300314070.31342@localhost>
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
========================================================================
next prev parent reply other threads:[~2015-01-30 12:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-30 11:55 what should be a simple question about sysfs attributes Robert P. J. Day
2015-01-30 12:06 ` Robert P. J. Day
2015-01-30 12:30 ` Robert P. J. Day [this message]
2015-02-01 21:44 ` John de la Garza
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.11.1501300415440.2741@localhost \
--to=rpjday@crashcourse.ca \
--cc=kernelnewbies@lists.kernelnewbies.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).