[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 1/2] libfsimage


On Mon, 2006-10-30 at 12:31 +0000, John Levon wrote:
> On Mon, Oct 30, 2006 at 11:14:00AM +0000, Stephen C. Tweedie wrote:
> > On Fri, 2006-10-27 at 19:58 +0100, John Levon wrote:
> > > These two patches re-work pygrub to use a generic C library for reading
> > > filesystem images. An immediate benefit is that there's no longer any
> > > external dependencies, so all the filesystems always 'just work'.
> > 
> > The downside is that it no longer picks up updates, fixes etc. from the
> > official upstream support for libext2fs / libreiserfs, so we're just
> > duplicating the places where filesystem support needs to be maintained.
> You mean upstream grub, not upstream libraries.

No, existing pygrub uses upstream libext2fs and libreiserfs, which are
the official maintained fs libraries, not extracted from grub.  It's
that relationship that I don't want to lose.

Having the same drivers in multiple places is just an unnecessary
maintenance burden.  It is somewhat justified in grub, which is a boot
loader and which by definition has to run before the full fs is up and
running.  But pygrub has no such excuse.

> > If xen packages are properly built, filesystems will Just Work anyway.
> On what operating system would that be?

On any OSes which can represent the relationship that the xen package
requires libext2fs and libreiserfs.  You missed out the quote that I was
replying to:

        "An immediate benefit is that there's no longer any external
        dependencies, so all the filesystems always 'just work'.
and I was pointing out that dealing with external dependencies is a
packaging issue, not an excuse for copying that external functionality
into the Xen tree.

> > That I can agree with.  But I'd rather see that API done as a wrapper
> > around existing upstream filesystem libraries, rather than forking fs
> > userspace support entirely.
> Vendors are free to write such plugins if they'd prefer it that way. As
> it is with using grub code, you get UFS support for free, we get ext2
> and reiserfs, and it's trivially extendible to anything that grub needs
> to boot...

Vendors are free to write extensions to pygrub already --- reiserfs and
ext2fs are already supported in such a way, through a modular python

I'd really far rather see a UFS module added for pygrub which uses an
external libUFS, rather than moving all fs-reading code into the xen
tree. where I just don't think it belongs.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.