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

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: <20061012235127.GA15767@kroah.com>
Date:	Thu, 12 Oct 2006 16:51:27 -0700
From:	Greg KH <greg@...ah.com>
To:	Chandra Seetharaman <sekharan@...ibm.com>
Cc:	Matt Helsley <matthltc@...ibm.com>,
	Paul Menage <menage@...gle.com>, linux-kernel@...r.kernel.org,
	ckrm-tech@...ts.sourceforge.net
Subject: Re: [ckrm-tech] [PATCH 0/5] Allow more than PAGESIZE data read in configfs

On Wed, Oct 11, 2006 at 04:26:00PM -0700, Chandra Seetharaman 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
> > attrbutes like this, use your own filesystem.
> 
> I would say it is a "large attribute" not "large numbers of attributes".

That attribute seems to violate the rule of "only one thing" and needs
to be parsed.  That does not seem like a good fit for configfs or sysfs.

> > 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.
> > 
> > What happened to your old ckrmfs?  I thought you were handling all of
> > this in that.
> 
> We decided to use an existing infrastructure instead of having our own
> file system.
> 
> configfs is a perfect fit for us, except the size limitation.

Then it's not a perfect fit, sorry, as you are trying to get it to do
things it is not supposed to, or designed to, do.

> BTW, it it not just CKRM/RG, Paul Menage as recently extracted the
> processes aggregation from cpuset to have an independent infrastructure
> (http://marc.theaimsgroup.com/?l=ckrm-tech&m=116006307018720&w=2), which
> has its own file system. I was advocating him to use configfs. But, he
> also has this issue/limitation. 

That's one reason it is so easy to just write your own filesystem then.
What is it these days, less than 200 lines of code?  I bet you can even
condence more things to make it 100 lines if you really try.  That seems
much more sane than trying to bend configfs into something different.

Why are people so opposed to creating their own filesystems?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/