Am 24.05.2011 10:36, schrieb Christoph Egger: > On 05/23/11 16:11, Kevin Wolf wrote: >> Am 23.05.2011 14:34, schrieb Christoph Egger: >>> >>> if given a block device, use the character device instead. >>> >>> From: Manuel Bouyer<bou...@netbsd.org> >>> Signed-off-by: Christoph Egger<christoph.eg...@amd.com> >> >> A useful commit message would explain why you're doing that. > > How about this: > > On NetBSD, the PV backend has to use the block device; but a > userland process is better with the character device interface. In > addition, a block device can't be opened twice; if the backend opens > it qemu can't and vice-versa.
Hm, what PV backend? Are you talking about Xen? If so, let's make this clear: On NetBSD a userland process is better with the character device interface. In addition, a block device can't be opened twice; if a Xen backend opens it, qemu can't and vice-versa. >>> diff --git a/block/raw-posix.c b/block/raw-posix.c >>> index 6b72470..d05f373 100644 >>> --- a/block/raw-posix.c >>> +++ b/block/raw-posix.c >>> @@ -136,11 +143,45 @@ static int64_t raw_getlength(BlockDriverState *bs); >>> static int cdrom_reopen(BlockDriverState *bs); >>> #endif >>> >>> +#if defined(__NetBSD__) >>> +static const char *raw_get_rawdevice(const char *filename) >>> +{ >>> + static char namebuf[PATH_MAX]; >>> + const char *dp = strrchr(filename, '/'); >>> + >>> + if (dp == NULL) { >>> + snprintf(namebuf, PATH_MAX, "r%s", filename); >>> + } else { >>> + snprintf(namebuf, PATH_MAX, "%.*s/r%s", >>> + (int)(dp - filename), filename, dp + 1); >>> + } >>> + fprintf(stderr, "%s is a block device", filename); >>> + filename = namebuf; >>> + fprintf(stderr, ", using %s\n", filename); >> >> Not sure if fprintf is a good idea here, but ok. > > I want to make it clear what file the qemu process has been > using. this is what log files are for, isn't it ? Yeah, while I don't like fprintfs in block driver code, I do agree that it makes some sense here. Kevin