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

[Greg KH <greg@kroah.com>]

On Wed, Oct 11, 2006 at 07:17:44PM -0700, Matt Helsley wrote:
> 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

Hold over from old procfs use of pci resources.  And now a requirement
that X uses this, after it was pointed out to me.

> /sys/block/hda/stat

I never have liked that, it belongs somewhere else.  Please move it.

> /sys/block/hda/dev

That is merely a dev_t, a single value.

Come on, there are way worse violators[1] of the "one value per file"
rule in sysfs that you could have found if you wanted to try to declare
how much it is not being followed in places.  But if you look, the ratio
of good vs. bad usage is still very high, and keeping it high is my
goal.

> > 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.

Feedback from whom?  I know I sure liked the fact that you did your own
filesystem, despite the bugs that were found in it at times :)

thanks,

greg k-h
-
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/