xfs
[Top] [All Lists]

Re: review: Simple patch to remove the dmapi support from xfsdump

To: Bill Kendall <wkendall@xxxxxxx>
Subject: Re: review: Simple patch to remove the dmapi support from xfsdump
From: Russell Cattelan <cattelan@xxxxxxxxxxx>
Date: Fri, 04 Aug 2006 13:08:52 -0500
Cc: Dean Roehrich <dean.roehrich@xxxxxxx>, Vlad Apostolov <vapo@xxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <44D379A6.9040200@xxxxxxx>
References: <44D10F9B.8090904@xxxxxxxxxxx> <44D2CA85.3040208@xxxxxxx> <20060804141012.GA26@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <44D36985.1090006@xxxxxxxxxxx> <20060804155850.GA3338@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <44D379A6.9040200@xxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird 1.5.0.4 (X11/20060614)
Bill Kendall wrote:

[snip]

3) Add make_handle() routine to libhandle. xfsdump's only dependencies
from libdm are dm_make_handle() and dm_handle_to_fsid() (the latter
of which is in libhandle as handle_to_fshandle(), I think).
Hmm looking at dm_handle_to_fsid: it calls parse_handle which appears
be quite dmapi specific and would require much of dm_handle.c?

I suppose we could move dm_handle.c into  libhandle ?
But that seems to be going in the wrong direction in terms of
correct code compartmentalization.

Since dmapi is only available  on Suse , Propack and somebody doing
a custom kernel, I'm not convinced that xfs dump/restore should
support dmapi no matter what.
The only time a problem might arise is somebody not using the shipped version
of xfs dump/restore on a Suse or propack system, in which case they
should either know what they are doing or get what they deserve.


4) Noop the existing hsm routines, and allow xfsdump to dlopen a
specified .so to override the default (noop) behavior. DMF could
then ship a .so implementing those functions.

Bill



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