Re: [PATCH 17/21] implement generic xfs_btree_split

[Dave Chinner <david@fromorbit.com>]

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 ;)

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com