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: [Xen-devel] [PATCH][TOOLS] libfsimage: portability fixes

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 ?

There doesn't seem to me to be any problem with pygrub's accesses
going through the buffer cache.

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 ?

Ian.

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