Re: configfs: return value for drop_item()/make_item()?

[Joel Becker <Joel.Becker@oracle.com>]

On Tue, Jan 23, 2007 at 02:49:59PM +0100, Michael Noisternig wrote:
> Sorry, I wasn't clear. I meant that it's not possible to let the user 
> create the parent directory via mkdir(2) within sysfs. I.e.
> # mkdir object  <-- create object/, configfs only
> # ls object
> type
> # echo b > object/type  <-- create b/, sysfs only
> # ls object
> type
> b/
> I cannot have both, sysfs and configfs functionality, within the same 
> module configuration file system tree.

	No, you can't have sysfs and configfs functionality in the same
exact portion of the tree.  But you can use both sysfs and configfs at
the same time in your driver.  The different parts will appear in the
different trees.  Up to you.

> 1. Is there any guarantee that strings passed to struct 
> configfs_item_operations->store_attribute are 0-terminated? If not, 
> there's not only potential for buffer overflows, but there already is - 
> in configfs_example.c, using simple_strtoul().

	There is no guarantee, but that's a bug.  The attribute handling
code came from sysfs.  I assume the initial assumption was that since
you can only copy a page, it's OK.  Clearly not the case.  sysfs fixed
this in October (commit 035ed7a49447bc8e15d4d9316fc6a359b2d94333).  I'll
be porting that over.  Thanks for noticing!

> 2. A minor one: I realize that the CONFIGFS_ITEM_NAME_LEN value of 20 is 
> taken over from sysfs, but in configfs a config_group now has 68 bytes 
> of size, and assuming that many times one would simply kmalloc a simple 
> struct config_group (without extending it) this would result in a waste 
> of 60 bytes per malloc. Do you want to keep that #define or reduce it to 
> 16? Just a thought...

	Hmm, interesting.  I'll look at that as well.

Joel

-- 

Life's Little Instruction Book #511

	"Call your mother."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/