|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [PATCH][TOOLS] libfsimage: portability fixes
Christoph Egger writes ("Re: [Xen-devel] [PATCH][TOOLS] libfsimage: portability
fixes"):
> On Friday 28 March 2008 11:42:15 Ian Jackson wrote:
> > Christoph Egger writes ("Re: [Xen-devel] [PATCH][TOOLS] libfsimage:
> portability fixes"):
> > > On Thursday 27 March 2008 16:36:45 Ian Jackson wrote:
> > > > I accept that it's not suitable for use as the full block backend, but
> > > > perhaps the answer is to pass pygrub an edited version of the device
> > > > name, or have pygrub edit it itself. If we were to use the non-raw
> > > > device for pygrub and the raw device for qemu-dm, would things work ?
> > >
> > > I don't think it would work without a lot of work on the backend device,
> > > if it is possible at all. For now, the backend assumes it was given a
> > > block device.
> >
> > I'm afraid I don't follow this at all. (What does `block device'
> > stand in opposition to?)
>
> "block device" is what is given in the guest setup with
> "disk = [ 'phy:/dev/wd0a,0x1,w' ]" (NetBSD syntax)
> "disk = [ 'phy:/dev/hda1,hda,w' ]" (Linux syntax)
Yes, I know that. But you say `the backend assumes it was given a
block device' and I was suggesting giving it the raw block device so
obviously we are talking at cross purposes.
Do you mean that it would somehow be difficult for the block backend
to talk to /dev/rwd0a instead ? Surely that would be more appropriate
in any case.
> > Is it possible for pygrub to open the non-raw device while the block
> > backend is using the raw device ? Or do you mean that the block
> > backend is already using the non-raw device and that you're having
> > pygrub use the raw device just so that you are able to use the same
> > underlying storage object twice simultaneously ?
>
> With changeset 17300, pygrub uses a raw device on NetBSD only.
> The block backend already opened the block device when pygrub
> opens the raw device.
Yes, so you said already. But you haven't answered my question.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|