lkml.org 
[lkml]   [2008]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/3] add a private data field within kobj_attribute structure (final#2)
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>


\
 
 \ /
  Last update: 2008-03-03 05:45    [W:0.807 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site