Here's a patch that accomplishes #3. Turns out no libhandle
changes were required. Built debian and rpm packages and
verified that dmapi/libdm were not mentioned in the dependencies,
and for debian that libdm was not mentioned in the build-deps either.

I'd still like to move the current hsmapi.c out of xfsdump, but it's
just not much of a priority right now.

Bill

Russell Cattelan wrote:
> 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
>>