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] [thread-next>] [day] [month] [year] [list]
Message-ID: <7086.1204177759@turing-police.cc.vt.edu>
Date:	Thu, 28 Feb 2008 00:49:19 -0500
From:	Valdis.Kletnieks@...edu
To:	Kohei KaiGai <kaigai@...jp.nec.com>
Cc:	greg@...ah.com, morgan@...nel.org, serue@...ibm.com,
	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] add a private data field within kobj_attribute structure (final#2)

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?

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ