From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Egger Subject: Re: [PATCH][TOOLS] libfsimage: portability fixes Date: Fri, 28 Mar 2008 11:08:17 +0100 Message-ID: <200803281108.18035.Christoph.Egger@amd.com> References: <200803261514.33378.Christoph.Egger@amd.com> <200803271613.33880.Christoph.Egger@amd.com> <18411.48909.186205.652361@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <18411.48909.186205.652361@mariner.uk.xensource.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com Cc: Ian Jackson List-Id: xen-devel@lists.xenproject.org On Thursday 27 March 2008 16:36:45 Ian Jackson wrote: > Christoph Egger writes ("Re: [Xen-devel] [PATCH][TOOLS] libfsimage:=20 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 ope= n, > > 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 =3D [ '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 =2D-=20 AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Gesch=E4ftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Registergericht Dresden: HRA 4896 vertretungsberechtigter Komplement=E4r: AMD Saxony LLC (Sitz Wilmington, Delaware, USA) Gesch=E4ftsf=FChrer der AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy