WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

Hi,

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
interface.  

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.

--Stephen



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel