linux-kernel - Re: [patch 12/21] perfmon2 minimal: sysfs interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <7c86c4470806170152rba7a4d0ieebca667ae81afaa@mail.gmail.com>
Date:	Tue, 17 Jun 2008 10:52:59 +0200
From:	"stephane eranian" <eranian@...glemail.com>
To:	"Greg KH" <greg@...ah.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [patch 12/21] perfmon2 minimal: sysfs interface

Greg,

I looked at this some more today.
I was able to remove the need for a custom attribute structure for one
of the objects.

I think it is not possible to use the generic kobj_attribute if you
need to refer to a particular
object in the show/store, i.e, not a global data structure. In other
words, if you need to use
the kobj pointer passed to the show() routine to access your data
structure, then you need to
rely on container_of() and thus the kobject MUST be embedded into the
data structure defining
the object. It cannot just be a kobject pointer.

The kobject interface to create and add objects come in two forms, the
one which requires
a ktype and the one which does not, i.e., kobject_create() and its
derivatives. It seems like
if you want to leverage the kobj_attribute, you need to avoid all
calls which require a ktype.
But then there is no such function which would work on an already
allocated kobject.
kobject_create_and_add() does allocate the kobject. You do not want
that because it means
the kobject is not embedded into your data structure anymore.

Am I missing something here?

Thanks.

On Sat, Jun 14, 2008 at 12:31 AM, stephane eranian
<eranian@...glemail.com> wrote:
> Greg,
>
>
>
> On Fri, Jun 13, 2008 at 5:53 AM, Greg KH <greg@...ah.com> wrote:
>> On Thu, Jun 12, 2008 at 02:54:15PM +0200, stephane eranian wrote:
>>>
>>> In any case, let me know if there are still things that must be
>>> changed/simplified in my file.
>>
>> This looks much better.  I wonder if you could use the "default" kobject
>> attributes, which might allow you to remove some of your show/store
>> wrappers, but in general, it's much better than before.
>>
> Well, I wondered about that myself, but I think I am missing one piece.
> The difference between some of the show/store functions and others
> is that if you look closely, you see that some make reference to global
> structures, e.g., pfm_controls, or call out to routines in others modules.
> For those, I have switched to the default attribute. But the other show/store
> functions need to access the particular object where the kobj is embedded.
> And for that, it seems you need to glue function:
>
> #define to_pmu(n) container_of(n, struct pfm_pmu_config, kobj)
>
> static ssize_t pfm_pmu_attr_show(struct kobject *kobj,
>                struct attribute *attr, char *buf)
> {
>        struct pfm_pmu_config *pmu = to_pmu(kobj);
>        struct pfm_attribute *attribute = to_attr(attr);
>        return attribute->show ? attribute->show(pmu, attribute, buf) : -EIO;
> }
>
> which basically calls the container_of() routine..
>
> Yet, I get the feeling that is the show routein gets the same kobj,
> then I could as well do the
> to_pmu() there. And the attr (use the the strcmp()) would be the default.
>
> If you tell me this is the way to go, I will certainly be happy to
> make the change and remove even
> more code!
>
>
> Thanks.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/