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: <20061011001514.GP7911@ca-server1.us.oracle.com>
Date:	Tue, 10 Oct 2006 17:15:14 -0700
From:	Joel Becker <Joel.Becker@...cle.com>
To:	Chandra Seetharaman <sekharan@...ibm.com>
Cc:	Paul Menage <menage@...gle.com>, akpm@...l.org,
	ckrm-tech@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [ckrm-tech] [PATCH 0/5] Allow more than PAGESIZE data read in configfs

On Tue, Oct 10, 2006 at 04:13:52PM -0700, Chandra Seetharaman wrote:
> On Tue, 2006-10-10 at 14:58 -0700, Joel Becker wrote:
> > 	Well, they now have to learn seq_file.  They now get to assume
> 
> If they are simple users, they don't have to "learn" seq_file semantics,
> they would just replace their sprintf's with seq_printfs (as my changes
> in OCFS2 show).

	The sed(1) is trivial sure.  seq_file isn't terribly complex.
It's less about mere code knowledge and more about intention.  Really,
it's how people understand configfs will deal with their attributes.

> "char *" can also be used to spew out large amount of data (ok, maybe up
> to PAGESIZE in configfs's case :). My point is that changing char * to
> seq_file doesn't necessarily "introduce" the issue (of spewing large
> amounts of data).

	If I see a seq_file, I assume there are multiple things to
iterate over.  Don't you?

> This issue is moot, unless you have intentions of changing the user
> interface of configfs to be anything other than a file system, isn't
> it ?

	It could be today, without much trouble.  The entire point is to
prevent client modules from implementing a filesystem or any filesystem
semantics.  They implement an item hierarchy with attributes.  The
attributes are read-write with ->show() and ->set().  The filesystem
should be invisible to the client.

> Now we are in need of *large* reads. We can add this feature and let it
> evolve to the next level later when somebody needs to *set* a large
> attribute.

	I don't want some set of ad-hoc rules based on legacy broken
ideas.  "Well, you can do this, or this, or this, or even this, and all
sort of work, but it's a mess" is not a good thing.

Joel

-- 

Life's Little Instruction Book #20

	"Be forgiving of yourself and others."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@...cle.com
Phone: (650) 506-8127
-
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/