In message <38E26EBC.850FAB53@timpanogas.com>, "Jeff V. Merkey" writes:
>
>
> Alan Cox wrote:
> >
> > > Yes, i've looked at Alan's Documentation stuff. And as always, Alan's
> > > work is absolutely excellent -- however, what's really needed is
> > > something like NT puts out with their IFS Kits, a sample VFS code
> >
> > Documenting the functions is the first project, then the structures.
> >
> > > to watch out for. Richard Gooch did a decent job on the vfs.txt file
> > > (it was better than nothing). We need more though to get on par with
> > > NT.
> >
> > Yep - but documentation is boring and uncool.. unfortunately too many programmers
> > believe this. Documentation is worth it just to be able to answer all your
> > mail with 'RTFM'
>
> I'll volunteer to create a NULL file system driver and maintain it --
> along with docs.
Do you mean you'd maintain a low-level block-level null f/s?
I'll be more than happy to maintain the stackable one + docs myself
indefinitely. But, I already have one, and I maintain it... :-) In fact,
Ion and I are maintaining it, so there's two people. So the more people
there are maintaining it, the better. We have to keep the templates current
b/c we have about a dozen active developers using wrapfs for their own stuff
(some even commercial products).
As for docs, it should be a joint effort. The vfs.txt file is a good start,
but it quickly gets out of sync w/ vfs changes. My wrapfs templates aren't
long, but they are complex: they behave like both VFS and a lower-level file
system. They have to, in order to achieve transparency in stacking and
multi-level stacking. Ion and I have pushed the limits of the VFS quite a
bit and managed to get stacking done w/ very little VFS changes (most of
which have long been incorporated).
In particular, the whole issue of when/how objects are created/destroyed
based on their refcount is messy. What we really need to clean our code up
is a file system method that is called each time the refcnt of a
file/inode/dentry/whatever is incremented or decremented.
And let's not even talk about fan-out file systems and what demands they put
on the VFS. But, I digress. It'll be great to have one or more people
formally maintaining such code.
> Jeff
Erez.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:26 EST