dropping dmapi support, was Re: [PATCH 00/17] pending patches

[Christoph Hellwig <hch@infradead.org>]

On Thu, Jun 03, 2010 at 12:01:46PM -0500, Alex Elder wrote:
> I would like to have a chance to submit an alternative to simply
> removing that code.  I recognize it sits in the first part of your
> patch series, and I will gladly do the work to rearrange them to
> put it at the end, in order to give me some time to develop my
> proposed change.
> 
> Basically what I'd like to do is update the DMAPI support code
> so that it is much better isolated.  I would like to replace
> the big ugly hunks that lie in common code paths with small
> function calls, so that their footprint is minimal and not
> distracting (along the lines of tracing calls).
> 
> I got a start on doing this, and had hoped to send the result
> pretty soon after your initial posting of the patch, but that
> work unfortunately got preempted by other more pressing stuff.
> I wanted to provide actual code to help make the discussion
> of the merits of removal versus cleanup more concrete.  I
> now think I'll be able to put something together within the
> next week or so.

I don't think it's a good idea.  I'm happy to not burn all bridges
and leave certain code structured in a way that makes adding it easier,
but if the hooks are as easy as you say above they can easily live in
an out of tree patchset.  The general Linux kernel policy is that we
don't keep hooks for out of tree code around, and I tend to agree to
it.  We kept all that dmapi cruft in, and it's never served any
purpose for us.  I think that HSM support is actually a very useful
feature, but the a kernel interface based on the DMAPI specification
much less so, and the horrible SGI implementation that used to be
in the XFS CVS tree even less so.

If you want to push a new one the metadata hooks really need to be
entirely outside the low-level filesystem, that is before calling
into the namespace inode operations, which is easily doable even
while keeping the current DMAPI core.

But what's much more difficult is the read/write path.  The dmapi
code really gets in the way there, and I have additional simplification
of this code pending that require this cruft to go away.  XFS currently
has a needlessly complicated write path, and getting closer to the
generic code will help us with lots of things like the upcoming multi
page write support.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs