From: Kohei KaiGai <kaigai@ak.jp.nec.com>
To: Valdis.Kletnieks@vt.edu
Cc: greg@kroah.com, morgan@kernel.org, serue@us.ibm.com,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] add a private data field within kobj_attribute structure (final#2)
Date: Mon, 03 Mar 2008 13:42:46 +0900 [thread overview]
Message-ID: <47CB81C6.6020402@ak.jp.nec.com> (raw)
In-Reply-To: <7086.1204177759@turing-police.cc.vt.edu>
Valdis.Kletnieks@vt.edu wrote:
> On Mon, 25 Feb 2008 15:10:27 +0900, Kohei KaiGai said:
>> [PATCH 1/3] add a private data field within kobj_attribute structure.
>
>> diff --git a/Documentation/kobject.txt b/Documentation/kobject.txt
>> index bf3256e..efa5d71 100644
>> --- a/Documentation/kobject.txt
>> +++ b/Documentation/kobject.txt
>> @@ -207,6 +207,12 @@ Both types of attributes used here, with a kobject that has been created
>> with the kobject_create_and_add(), can be of type kobj_attribute, so no
>> special custom attribute is needed to be created.
>>
>> +The simple kobj_attribute is prototyped at include/linux/kobject.h, and can
>> +contain your own show()/store() method and private data.
>> +When an attribute is accessed, these methods are invoked with kobject,
>> +kobj_attribute and read/write buffer. The method can refer the private data
>> +via given kobj_attribute, to show/store itself in the text representation.
>> +
>> See the example module, samples/kobject/kobject-example.c for an
>> implementation of a simple kobject and attributes.
>
> OK, I'm an idiot, so I re-read this several times, and looked at patch 3/3
> that added the sample code, and I'm still confoozled.
>
> Who creates/destroys/manages this "read/write buffer", and/or how does the
> method know how large a buffer is available, so (for example) it can use the
> strn* versions of string functions to be sure not to run off the end? Does
> this buffer have any lifetime rules attached to it?
This "read/write buffer" is managed by sysfs filesystem.
Sysfs is invoked via kernel VFS subsystem, when user calls read(2) or write(2).
In the read(2) case, sysfs_read_file() is invoked, allocates a page for buffer,
and calls the show() method to generate the containts of this pseudo file entry.
Therefore, show() and store() method does not need to manage this buffer.
When store() method is invoked with data from userspace, sysfs terminate it with
'\0' implicitly. The size of buffer is also limited to PAGE_SIZE implicitly.
Can you make it clear?
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
next prev parent reply other threads:[~2008-03-03 4:43 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-25 6:06 [PATCH 0/3] exporting capability name/code pairs (final#2) Kohei KaiGai
2008-02-25 6:10 ` [PATCH 1/3] add a private data field within kobj_attribute structure (final#2) Kohei KaiGai
2008-02-25 6:51 ` Greg KH
2008-02-25 6:57 ` Kohei KaiGai
2008-02-25 7:47 ` Greg KH
2008-02-25 10:04 ` Kohei KaiGai
2008-02-26 20:09 ` Greg KH
2008-02-28 5:49 ` Valdis.Kletnieks
2008-03-03 4:42 ` Kohei KaiGai [this message]
2008-02-25 6:10 ` [PATCH 2/3] exporting capability name/code pairs (final#2) Kohei KaiGai
2008-02-26 14:55 ` Andrew G. Morgan
2008-02-26 20:58 ` Serge E. Hallyn
2008-03-07 4:30 ` Kohei KaiGai
2008-03-07 4:53 ` Greg KH
2008-02-25 6:10 ` [PATCH 3/3] a new example to use kobject/kobj_attribute (final#2) Kohei KaiGai
2008-04-22 11:12 ` [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) KaiGai Kohei
2008-04-22 11:17 ` [PATCH 1/3] add a private data field within kobj_attribute structure KaiGai Kohei
2008-04-22 11:18 ` [PATCH 2/3] exporting capability name/code pairs KaiGai Kohei
2008-04-22 11:18 ` [PATCH 3/3] a new example to use kobject/kobj_attribute KaiGai Kohei
2008-04-22 19:29 ` [PATCH 0/3] exporting capability name/code pairs (for 2.6.26) Alexey Dobriyan
2008-04-23 0:38 ` KaiGai Kohei
2008-04-23 7:03 ` Alexey Dobriyan
2008-04-23 7:37 ` KaiGai Kohei
2008-05-13 22:12 ` Alexey Dobriyan
2008-05-14 0:34 ` KaiGai Kohei
2008-04-23 5:37 ` Chris Wright
2008-04-23 7:15 ` KaiGai Kohei
2008-05-14 0:36 ` KaiGai Kohei
2008-05-14 0:52 ` Chris Wright
2008-05-14 5:57 ` KaiGai Kohei
2008-05-15 5:48 ` Andrew Morgan
2008-05-15 7:47 ` KaiGai Kohei
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=47CB81C6.6020402@ak.jp.nec.com \
--to=kaigai@ak.jp.nec.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=morgan@kernel.org \
--cc=serue@us.ibm.com \
/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