what should be a simple question about sysfs attributes ...

[Robert P. J. Day]

... but will take a while to set up. i want to write a short tutorial
on kobjects, sysfs and attributes so i want to make absolutely sure i
understand them (which is something i should understand anyway. :-)

  from sysfs.h and kobject.h, we have the definition of the generic
kernel-wide "attribute" and "kobj_attribute" structures:

struct attribute {
        const char              *name;
        umode_t                 mode;
#ifdef CONFIG_DEBUG_LOCK_ALLOC
        bool                    ignore_lockdep:1;
        struct lock_class_key   *key;
        struct lock_class_key   skey;
#endif
};

and

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);
};

  so what the above shows is that a "kobj_attribute" contains an
"attribute" and has, as its internal callback routines, functions that
deal only with completely generic kobject and kobj_attribute pointers.
so if i'm creating a number of attributes for some kobject i've
created, and i'm associating show and store routines with each one,
those show and store routines must have that prototype.

  for example, look at mm/ksm.c and how the attributes and callback
routines are defined -- here's one:

////////

static ssize_t full_scans_show(struct kobject *kobj,
                               struct kobj_attribute *attr, char *buf)
{
        return sprintf(buf, "%lu\n", ksm_scan.seqnr);
}
KSM_ATTR_RO(full_scans);

static struct attribute *ksm_attrs[] = {
        &sleep_millisecs_attr.attr,
        &pages_to_scan_attr.attr,
        &run_attr.attr,
        &pages_shared_attr.attr,
        &pages_sharing_attr.attr,
        &pages_unshared_attr.attr,
        &pages_volatile_attr.attr,
        &full_scans_attr.attr,
#ifdef CONFIG_NUMA
        &merge_across_nodes_attr.attr,
#endif
        NULL,
};

static struct attribute_group ksm_attr_group = {
        .attrs = ksm_attrs,
        .name = "ksm",
};

////////

  so the way i've always interpreted the above is that, when i finally
register the attributes with the kernel, i am registering really just
the underlying generic "attribute" structure and, when i try to access
that attribute file, it automatically dereferences to the enclosing
kobj_attribute structure to pick up the corresponding show() and
store() routines associated with that attribute.

  so the first question is, is my understanding correct? if, in the
above case, whenever i try to access one of the ksm attributes in
/sys/kernel/mm/ksm, does the kernel take the reference to that
*generic* attribute and automatically dereference/container_of() on it
to get the enclosing kobj_attribute structure to pick up the
corresponding show() and store() routines? asked a shorter way, is it
assumed that a kobject attribute is *always* contained inside a
kobj_attribute structure? and that the code in mm/ksm.c is an example
of how to add individual show() and store() routines to such
attributes?

  now here's part 2, and it's just a followup from the above. the
second variation for attributes is what you see in cpufreq.c. rather
than each attribute having its own callback routines, that code
defines a prototype for cpufreq-*specific* show and store routines and
a cpufreq-specific "freq_attr":

struct freq_attr {
        struct attribute attr;
        ssize_t (*show)(struct cpufreq_policy *, char *);
        ssize_t (*store)(struct cpufreq_policy *, const char *, size_t
count);
};

  *however* (and here's the thing i want to make sure i understand),
when you register all of the cpufreq attribute files, each one still
has to be interpreted as if it's part of a generic kobj_attribute
structure with generic show() and store() routines, so what cpufreq
does is define two generic show() and store() routines, and a couple
helper macros that allow those two routines to then dereference to the
appropriate cpufreq_policy and freq_attr pointers, then call the
attribute-specific show() and store() routines:

//////////

#define to_policy(k) container_of(k, struct cpufreq_policy, kobj)
#define to_attr(a) container_of(a, struct freq_attr, attr)

static ssize_t show(struct kobject *kobj, struct attribute *attr, char *buf)
{
        struct cpufreq_policy *policy = to_policy(kobj);
        struct freq_attr *fattr = to_attr(attr);
        ... snip ...
}

static ssize_t store(struct kobject *kobj, struct attribute *attr,
                     const char *buf, size_t count)
{
        struct cpufreq_policy *policy = to_policy(kobj);
        struct freq_attr *fattr = to_attr(attr);
        ... snip ...
}

//////////

  and at the end of that file, the attributes are all registered with:

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,
};

which i interpret as saying that all of those attributes should be
registered with the same single show() and store() routines (as
opposed to ksm, which used different show() and store() routines for
each attribute.

  in closing(?), as i understand it, when i access a kobject attribute
file, it is assumed that that attribute is enclosed in a
kobj_attribute structure, which contains the generic show() and
store() routines, and i've seen two patterns for that:

1) in mm/ksm.c, each attribute is *directly* registered with callback
routines with that prototype specific to that attribute, or

2) in cpufreq.c, all attributes are, in one operation, all registered
with the *same* pair of generic callback functions, and those
functions are then required to dereference the generic pointers to be
able to call the appropriate callbacks for the given attribute.

  do i have this about right?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================