Nathan Scott <nathans@xxxxxxx> writes:
> On Mon, Feb 04, 2002 at 08:55:05PM +1000, monkeyiq wrote:
> > ...
> > BTW what is the mood on acceptance of a patch for xfs_bmap to have
> > an --xml option to dump the same info from -v as an XML 1.0 document?
> > this would make it nice and easy to make an extent viewer as either
> > a gtk+ app or a php4 app.
> Would this introduce a new dependency on libxml? If so,
No. I was just going to build the xml using snprintf() not the DOM
interface. So there would only be a slight increase in exe size due
to code similar to the -v code being there to make XML. there would
be no new libs or dependancies. Though the manner in which the extents
are obtained in xfs_bmap yells out to me that there should be a library
call something like
struct getbmapx* getExtents( int fd );
because that little bit of code that does a similar thing in xfs_bmap
seems hairy enough to only want it in one function that is available to
all xfs users rather than replicated throughout many xfs using apps.
Maybe if there was a libxfsprogs.a the clients could statically link
to that lib and thus appear just as they do now, only there would be
a static lib for other xfs client apps to link to and enjoy. But, one
step at a time :)
> it shouldn't be added into the xfsprogs xfs_bmap - I'd
> suggest making a new program based on xfs_bmap.c (its only
> ~400 lines or so), add the new code in there, and distribute
> that separately.
> We have always tried to keep xfsprogs' dependencies to the
> bare minimum, so that people can avoid installing software
> they don't necessarily want.