kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
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
========================================================================

  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).