qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: RFC v2: blockdev_add & friends, brief rationale, QM


From: Markus Armbruster
Subject: Re: [Qemu-devel] Re: RFC v2: blockdev_add & friends, brief rationale, QMP docs
Date: Fri, 18 Jun 2010 09:06:41 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Anthony Liguori <address@hidden> writes:

> On 06/17/2010 03:20 AM, Kevin Wolf wrote:
>> Am 16.06.2010 20:07, schrieb Anthony Liguori:
>>    
>>>>    But it requires that
>>>> everything that -blockdev provides is accessible with -drive, too (or
>>>> that we're okay with users hating us).
>>>>
>>>>        
>>> I'm happy for -drive to die.  I think we should support -hda and
>>> -blockdev.
>>>      
>> -hda is not sufficient for most users. It doesn't provide any options.
>> It doesn't even support virtio. If -drive is going to die (and we seem
>> to agree all on that), then -blockdev needs to be usable for users (and
>> it's only you who contradicts so far).
>>    
>
> I've always thought we should have a -vda argument and an -sda
> argument specifically for specifying virtio and scsi disks.

"-hda F" is a cognitive dead end: if you need more control, knowing -hda
doesn't give you a better idea where to look for it than not knowing it.

This is different with "-drive file=F".  It can grow with the user's
needs.

-blockdev's primary mission is clean host / guest separation, and clean
interface to block devices for QMP and for config files.

If it turns out to be too verbose and complex for everyday command line
use, we shouldn't take -hda & similar as excuse for leaving it there.
We still need a usable option that can grow with the user's needs.  And
it better be able to grow to the point where you have full control over
the device model, i.e. you use -device.

[...]



reply via email to

[Prev in Thread] Current Thread [Next in Thread]