All of lore.kernel.org
 help / color / mirror / Atom feed
From: john@jjdev.com (John de la Garza)
To: kernelnewbies@lists.kernelnewbies.org
Subject: what should be a simple question about sysfs attributes ...
Date: Sun, 1 Feb 2015 13:44:12 -0800	[thread overview]
Message-ID: <20150201214411.GB71227@crux.local> (raw)
In-Reply-To: <alpine.LFD.2.11.1501300415440.2741@localhost>

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

      reply	other threads:[~2015-02-01 21:44 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
2015-02-01 21:44   ` John de la Garza [this message]

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=20150201214411.GB71227@crux.local \
    --to=john@jjdev.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.