[Top] [All Lists]

Re: [PATCH 17/21] implement generic xfs_btree_split

To: Christoph Hellwig <hch@xxxxxx>
Subject: Re: [PATCH 17/21] implement generic xfs_btree_split
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Sat, 2 Aug 2008 11:33:01 +1000
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20080801195507.GK1263@xxxxxx>
Mail-followup-to: Christoph Hellwig <hch@xxxxxx>, xfs@xxxxxxxxxxx
References: <20080729192113.493074843@xxxxxxxxxxxxx> <20080729193137.GR19104@xxxxxx> <20080730065349.GR13395@disturbed> <20080801195507.GK1263@xxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
On Fri, Aug 01, 2008 at 09:55:07PM +0200, Christoph Hellwig wrote:
> > This is where I begin to question this approach (i.e. using
> > helpers like this rather than specific ops like I did). It's
> > taken me 4 ??r 5 patches to put my finger on it.
> > 
> > The intent of this factorisation is to make implementing new btree
> > structures easy, not making the current code better or more
> > managable. The first thing we need is is btrees with different
> > header blocks (self describing information, CRCs, etc). This above
> > function will suddenly have four combinations to deal with - long and
> > short, version 1 and version 2 header formats. The more we change,
> > the more this complicates these helpers. That is why I pushed
> > seemingly trivial stuff out to operations vectors - because of the
> > future flexibility it allowed in implementation of new btrees.....
> > 
> > I don't see this a problem for this patch series, but I can see that
> > some of this work will end up being converted back to ops vectors
> > as soon as we start modifying between structures....
> Maybe.  But even when we convert it to ops vectors it should not
> be the btree implementation vector, but a btree_block_ops that's
> implemented once instead of duplicated for the alloc vs ialloc
> btree.

Yes, that makes sense - I had sort of headed that way, but it
was not fully though out...

> And for now having all this in xfs_btree.c makes reading
> and working on the patch series easier, so..

Fair enough - do the work when we implement a new btree ;)


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>