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: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1

> > OK, it's not a very cunning hack to do but it makes the blkback driver
> > more complex whilst duplicating functionality that's already in the
> > kernel.  You'd have to deal with a load of VFS APIs as well as the
> > existing block APIs, which would be unfortunate.
>
> Maybe reuse the loopback code?  Maybe it has an abstract device->file
> conversion group of functions/structures.

Arguably the ideal in-kernel solution is to fix the loopback driver itself.

> > Does anybody know why the existing loopback device performs badly anyway?
> >  As Adam says, it shouldn't be rocket science to make it work well...
>
> Default kernel limit of 8 loops.  Requires a recompile, and then probably
> only supports 256 devices max.

Yup the default limit could (arguably) be raised in our default config.  I was 
especially referring to the performance, which is reported to be rather bad.

> > > blktap?  Is that similiar to what I described above?
> >
> > Blktap allows you to write a userspace program to provide a block device
> > to another domain.  It makes what you described a bit more
> > straightforward than implementing directly in the blkback driver.
>
> That would be more complex I would think then doing file access in the
> kernel.

I'm not sure it would, the blocktap library is designed for this sort of 
thing.  From what Andy says there is actually already a tool to do it, which 
might be worth investigating further.

Cheers,
Mark

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

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