Re: [PATCH][TOOLS] libfsimage: portability fixes

[Christoph Egger <Christoph.Egger@amd.com>]

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)

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

Christoph

-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy