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
