Andi Kleen wrote:
>
> On Tue, Jun 06, 2000 at 01:42:42AM -0700, Hans Reiser wrote:
> > Andi Kleen wrote:
> > >
> > > On Tue, Jun 06, 2000 at 12:11:08AM -0700, Hans Reiser wrote:
> > > > I want to add reiserfs to linux, not merge it into ext3. This is the crux of
> > > > the argument. Alan says I should wait until ext3 is added so that I can let
> > > > them write part of our FS for us.
> > >
> > > I actually didn't read it as that. He wrote that it needs checking
> > > what parts of the journaling code can use common hooks.
> >
> > Expressed this way I of course agree that it should be done. I don't see why it
> > should cause reiserfs integration to be delayed though. ReiserFS is easy to
> > rewrite.:-) I don't see what the problem is with minorly rewriting reiserfs in
> > 2.5 to match whatever API changes are called for. I also hope that we will
> > contribute some of them. zam is right now working on memory pressure hooks, and
> > they are intended to be general hooks that we hope the rest of the kernel folks
> > will like once we have a patch working to submit.
> >
> > If you say evolve toward a common journaling operations VFS API in 2.5, I nod my
> > head. If you say delay reiserfs for that API to be defined, I ask why? Define
> > it and we'll change reiserfs! It is not like we aren't used to changing
> > reiserfs extensively every year to deal with VFS changes.:-/
>
> The common API was just a comment/extension from me.
A good one though, and it would be nice if this thread became constructive.
>
> The main point are
> the common hooks. In the early day of ext3/reiser every fs had its own
> patches to buffer.c which usually conflicted. reiserfs solved it by
> copying huge chunks of buffer.c into buffer2.c and using that. ext3
> still used some hooks in buffer.c directly last time I checked. The code
> duplication in buffer2.c is certainly bad and could take some
> ``common hooks''. Maybe Linus thinks that's ok, Alan apparently thinks it
> is not, we'll see how it ends.
I am simple, give me a hook and I'll use it, if not I'll try to avoid making
demands of others to change their code to accomodate me, and I'll do that by
using code duplication. Give us a license to change buffer.c code to be more
general and we will.
>
> Another issue is the hook needed to tell the journal
> about memory pressure (this all has nothing to do with the VFS)
Why shouldn't it be a VFS operation?
>
> -Andi
-
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 : Wed Jun 07 2000 - 21:00:24 EST