Re: [PATCH 16/21] implement generic xfs_btree_lshift

[Christoph Hellwig <hch@xxxxxx>]

On Sat, Aug 02, 2008 at 11:28:03AM +1000, Dave Chinner wrote:
> It might make sense to go back to a single implementation,
> though at the time I did it it made sense to split the move/copy
> operations because it made both cases simpler. Seeing as you've
> stuck more closely to the original structure of the code, the
> distinction is not as great as so it might be best to go back to a
> single memmove based interface.

Btw, one other idea I still have in my mind is to add rec_len
and key_len methods to the core btree code, that way quite a few
methods (ptr_addr, key_addr, rec_addr, set_key, move_keys, move_recs,
copy_keys, copy_recs, log_keys, and log_recs) could be implemented
in common code, leaving the actual btree implementations really small.