Re: [Qemu-devel] [PATCH] block/raw-posix: use a character device if a block device is given

[Kevin Wolf <kwolf@redhat.com>]

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<bouyer@NetBSD.org>
>>> Signed-off-by: Christoph Egger<Christoph.Egger@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