On Thursday 27 March 2008 16:36:45 Ian Jackson wrote:
> Christoph Egger writes ("Re: [Xen-devel] [PATCH][TOOLS] libfsimage:
portability fixes"):
> > Everytime when I submitted a patch where I changed /bin/bash to /bin/sh
> > John Levon came up with a "Build is broken on Solaris" message.
> > The fix was always the same: Use $(SHELL) as this is explicitely set for
> > Solaris.
>
> People whose /bin/sh is that badly broken deserve to lose IMO - that
> is to say, we shouldn't inconvenience other people for their benefit.
> We've had this conversation before.
>
> But in any case your syntax was completely wrong and the script has
> #!/bin/sh at the top already so I don't see why this is relevant to
> you.
>
> > On Thursday 27 March 2008 11:54:41 Ian Jackson wrote:
> > > Christoph Egger writes ("[Xen-devel] [PATCH][TOOLS] libfsimage:
> > > portability Please forgive my ignorance: Does NetBSD offer a different
> > > (non-raw) device which does not have this requirement. If so perhaps
> > > we should be using it instead - if not, why not ?
> >
> > The raw device pass requests directly to the underlying device, with
> > only check/adjustments against the partition bounds. Especially it won't
> > try to do read/modify/write for write requests, or expand the read if
> > it's not sector-aligned.
>
> Yes, but these aren't desirable in this case.
>
> > The block device doesn't have this restriction, but allows only ONE open,
> > therefore it is not usable by pygrub. It also has other side-effects
> > (as it goes through the buffer cache), it's definitively not useable for
> > the NetBSD block device *backend* or for qemu-dm I/O.
>
> The problem is that pygrub wants to open the disk multiple times ?
> Or is it that xend has already plumbed in the device to qemu-dm or
> what have you, and that prevents a second open ?
The block backend opens the block device before pygrub is started.
So, when you have "disk = [ 'phy:/dev/bla,blub,w' ]" in your setup you get
an EBUSY when pygrub tries to open the block device.
> 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.
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home