[Thanks for copying me on this]
On Fri, Aug 04, 2006 at 01:53:45PM -0700, Matt Helsley wrote:
> On Fri, 2006-08-04 at 13:11 -0700, Chandra Seetharaman wrote:
> > On Fri, 2006-08-04 at 13:00 -0700, Andrew Morton wrote:
> > > On Fri, 04 Aug 2006 12:14:23 -0700
> > > Chandra Seetharaman <[EMAIL PROTECTED]> wrote:
> > >
> > > > On Fri, 2006-08-04 at 00:20 -0700, Paul Menage wrote:
...snip...
> > > > This is the plan. But, the configfs maintainer was not happy with that
> > > > feature addition as it will make the file system more complex.
> > >
> > > In a contest between "complex" and "having some pathetic limitation",
> > > we'll
> > > take "complex".
> > >
> > > Did the configfs maintainer (was it Mark?) have some other proposed fix?
I don't disagree with your "complex" vs "pathetic limitation"
argument, but I don't see it that way. My proposed fix was that long
data dumps belong in sysfs or procfs, not configfs. configfs is about
creating objects and modifying attributes. It's not "configfs ||
sysfs", it's "configfs && sysfs".
Certainly creating groups via subdirs or even symlinks is also a
valid configfs method. I'm not familiar with the ckrm requirements
enough to be sure this is what they are talking about, but if they had a
list of "things":
config/ckrm/things/
1
2
3
and a list of groups:
config/ckrm/groups/
family1
family2
then configfs' symlink is a great way to join them:
ln -s config/ckrm/things config/ckrm/groups/family1
The callback for links allows access checks, and allows the ckrm code to
do whatever internal linkage it wants. The symlink is internally a
direct link (list_head) htat will lock family1 into place until the link
is removed.
I make this point because I got the impression from the bits
below that you want to add things to these groups. Which makes sense.
If your groups needed attributes, you could even have
configfs/ckrm/groups
family1
attr1
attr2
members
but you probably already guessed that.
> > > If not, a seq_file-based fix sounds OK to me. We don't have to actually
> > > merge it until something which needs it is also in-tree, but a 1000-item
Please, help me be VERY CAREFUL about this. configfs is not and
was never designed to be a catch-all filesystem. It is purposely small
and simple, so that it doesn't become the next sysfs or procfs. The
more windows you allow people, the more they can screw up lifetimes &tc.
If you need to dump a lot of data, sysfs and procfs can do this just
fine. GFS2-DLM and OCFS2 both make use of configfs AND sysfs, doing
config-y things in configfs and other things in sysfs.
I've had the issue of large configuration bits in the back of my
mind for a while, really. In general, I do not want to expose any
generic "add some generic thing to the tree" functionality EVER, because
that leads to the abuses we see in procfs and sysfs. The
file-as-attribute mechanism it uses (and sysfs uses in the simpler
cases) is a nicely locked down, purpose-based interface.
When I think about "Who else could take advantage of configfs?",
the number one candidate I can think of is device-mapper. Something
like:
# mkdir config/dm/dm-0
# echo linear > config/dm/dm-0/type
# echo '0 2000 /dev/sda1 0' > config/dm/dm-0/table
# echo 1 > config/dm/dm-0/live
but this runs into the large attribute problem as well. device-mapper
tables can easily be bigger than 4K, so config/dm/dm-N/table wouldn't be
big enough.
I'm open to suggestions as to how to create a "large attribute"
type, but it really should be something that is purpose-based. configfs
is for userspace to create a kernel object and get or set attributes on
that object. That object might create its own interfaces in sysfs, it
might do other things, who knows. "Large attribute" support should not
be an open-ended chance to create another sysfs. If it belongs in
sysfs, it belongs in sysfs, not configfs.
> > > limit (depends on PAGE_SIZE, too?) is silly.
PAGE_SIZE is a holdover from the sysfs attr code I ripped off.
Perhaps MIN_PAGE_SIZE is better. 4K is as much as one should need for
this. It's not right that an ia64 can put more data in than an x86.
We should have a common size for an attr value across all platforms.
Joel
--
"The nearest approach to immortality on Earth is a government
bureau."
- James F. Byrnes
Joel Becker
Principal Software Developer
Oracle
E-mail: [EMAIL PROTECTED]
Phone: (650) 506-8127
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech
