Re: [ckrm-tech] [PATCH 0/5] Allow more than PAGESIZE data read in configfs

[Matt Helsley <matthltc@us.ibm.com>]

On Wed, 2006-10-11 at 15:39 -0700, Greg KH wrote:
> On Tue, Oct 10, 2006 at 06:28:51PM -0700, Joel Becker wrote:
> > On Tue, Oct 10, 2006 at 05:49:59PM -0700, Matt Helsley wrote:
> > > 	We want to be able to export a sequence of small (<< 1 page),
> > > homogenous, unstructured (scalar), attributes through configfs using the
> > > same file. While this is rather specific, I'd guess it would be a common
> > > occurrence.
> > 
> > 	Pray tell, why?  "One attribute per file" is the mantra here.
> > You really should think hard before you break it.  Simple heuristic:
> > would you have to parse the buffer?  Then it's wrong.
> 
> I agree.  You are trying to use configfs for something that it is not
> entended to be used for.  If you want to write/read large numbers of

	I disagree with your assertion that we're abusing configfs. "one value
per file" is not the purpose of configfs.

	The purpose of configfs is to allow userspace to create and manipulate
kernel objects whose lifetime is under the control of userspace. That
perfectly matches the idea of being able to create, manipulate, and
destroy a resource group from userspace.

	"one value per file" is a phrase describing what configfs and sysfs
files should normally look like. However it's not a rule since there is
precedent for sysfs files that require parsing:
/sys/devices/pciXXXX:XX/XXXX:XX:XX.X/resource
/sys/block/hda/stat
/sys/block/hda/dev

	These are counterexamples to your assertion below that "one value per
file" is a rule.

> attrbutes like this, use your own filesystem.

	This conflicts with the idea of reusing kernel code that was made to be
reused. Except for this 1 page limit configfs is nearly a perfect match.
I doubt we'd get a favorable reaction if we said:
	"OK, let's copy configfs then remove the page size limit."

> configfs has the same "one value per file" rule that sysfs has.  And
> because your userspace model doesn't fit that, don't try to change
> configfs here.

Please see my counterexample above.

> What happened to your old ckrmfs?  I thought you were handling all of
> this in that.

	We dropped RCFS more than 1 year ago after feedback suggested we should
try to share as much kernel code as possible. Other than the 1 page
limit to the list of pids, configfs is a perfect match for what we need.

Cheers,
	-Matt Helsley