Message-ID: <20061014061723.GA26016@kroah.com>
Date:	Fri, 13 Oct 2006 23:17:23 -0700
From:	Greg KH <greg@...ah.com>
To:	Matt Helsley <matthltc@...ibm.com>
Cc:	Chandra Seetharaman <sekharan@...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 Fri, Oct 13, 2006 at 04:40:08PM -0700, Matt Helsley wrote:
> On Thu, 2006-10-12 at 16:51 -0700, Greg KH wrote:
> 
> <snip>
> 
> > > 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
> 
> For my_school_project_fs perhaps 200 lines is sufficient.
> 
> Paul Menage's patch which Chandra was referring to:
> 
> http://lkml.org/lkml/2006/9/28/104
> 
> is 1700 insertions. RCFS was around 1500 lines -- similar to Paul's
> patch -- before we moved to configfs and reduced that to about 300-400
> lines. This suggests we'd need around 1500 lines of filesystem code --
> 7.5 times your estimate.

Then I suggest that you are doing something extremely wrong here.  The
base filesystem code for both debugfs and securityfs, is around 200
lines of code, including comments.  And they are both not
"my_school_project_fs".

If you want to get a bit fancier, and parse some mount options and
provide a persistant mount state, like usbfs, it grows to about 350
lines of code.

Again, not a "fake" filesystem by any means.

And, for another example, ndevfs was posted to lkml over a year ago as a
bad joke and can be found at:
	http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/bad/ndevfs.patch
and weighs in at a whopping 249 lines for all of inode.c (comments and
whitespace included.)  It was a full-blown filesystem that handled
almost exactly what you will need to handle.

So please, before you critise me for not knowing exactly how much work
it takes to implement a ram-based filesystem for something like this,
take a look at a few of the already published and shipping
implementations, and note who wrote them...

Otherwise you look quite foolish.

> > 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.
> 
> 	I don't agree. I think it's insane not to use configfs just because we
> need a list of pids for each group of tasks.

Perhaps because your usage is not what it is intended for?  Yeah, I
know, if all you have is a hammer...

> > Why are people so opposed to creating their own filesystems?
> 
> 	There are lots of reasons not to create your own filesystem. When
> you're not already a kernel maintainer it's no small task to create and
> get a non-trivial filesystem accepted into the kernel. Getting people to
> review whole new filesystems has its own problems:
> 
> http://www.ussg.iu.edu/hypermail/linux/kernel/0610.1/1928.html

There's a world of difference between something as complex as unionfs
and something that merely makes a few calls to the libfs code already in
the kernel.

And if you don't realize this, then yes, I would not recommend that you
should write your own fs.  But I would then recommend that the task then
be passed on to someone else in your group who does have the capability
to do so...

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/

Powered by blists - more mailing lists