[Top] [All Lists]

Re: Preallocation and Ferris

To: Nathan Scott <nathans@xxxxxxx>
Subject: Re: Preallocation and Ferris
From: monkeyiq <monkeyiq@xxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 5 Feb 2002 10:18:52 +1000
Cc: monkeyiq <monkeyiq@xxxxxxxxxxxxxxxxxxxxx>, linux-xfs@xxxxxxxxxxx
Sender: owner-linux-xfs@xxxxxxxxxxx
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.
> cheers.
> -- 
> Nathan


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