| 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@sgi.com> |
| References: | <44D10F9B.8090904@thebarn.com> <44D2CA85.3040208@sgi.com> <20060804141012.GA26@kickball-mn.Central.Sun.COM> <44D36985.1090006@thebarn.com> <20060804155850.GA3338@kickball-mn.Central.Sun.COM> <44D379A6.9040200@sgi.com> |
| Sender: | xfs-bounce@xxxxxxxxxxx |
| User-agent: | Thunderbird 1.5.0.4 (X11/20060614) |
Bill Kendall wrote: [snip]
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.
|
| Previous by Date: | Re: review: Simple patch to remove the dmapi support from xfsdump, Eric Sandeen |
|---|---|
| Next by Date: | Re: review: Simple patch to remove the dmapi support from xfsdump, Bill Kendall |
| Previous by Thread: | Re: review: Simple patch to remove the dmapi support from xfsdump, Eric Sandeen |
| Next by Thread: | Re: review: Simple patch to remove the dmapi support from xfsdump, Bill Kendall |
| Indexes: | [Date] [Thread] [Top] [All Lists] |