[Qemu-devel] Re: RFC: blockdev_add & friends, brief rationale, QMP docs

[Avi Kivity <avi@redhat.com>]

On 05/31/2010 01:54 PM, Markus Armbruster wrote:
>
>> We expose some of the cache property to the guest.  IMO we need the
>> cache property to be both guest and host, with qemu bridging the
>> impedance mismatch if needed.
>>      
> Yes.
>
> How should the device properties look like?
>    

write_cache=enabled|disabled|none? (disabled can be enabled by the 
guest, but none cannot)
barrier=supported|unsupported?

Need to look at our supported interfaces and see what's the LCM.

>>> rerror, werror                      host, guest drivers will reject
>>>                                         values they don't support
>>>
>>>        
>> Did you mean 'block format drivers will reject'?
>>      
> No.  Actual implementation is in the guest drivers,
> e.g. ide_handle_rw_error().
>    

That is not a guest driver.  It is a device model.  A guest driver is 
something you modprobe.

> I see this as the host outsourcing the actual work to guest drivers.
> Guest drivers that can't do the work should complain.  Right now, they
> silently ignore the order.
>    

With the terminology change, it makes a bit of sense.

>
>> Maybe we want an explicit blockdev_eject instead, not sure.
>>      
> Either blockdev_change (can eject, insert with auto-eject) or completely
> orthogonal blockdev_eject (can only eject) + blockdev_insert (can only
> insert, no auto-eject), I'd say.
>    

I prefer the latter, especially as eject has numerous variants (software 
locked eject button, force=true to unwrap paper clip and insert into 
pinhole, tray ejects violently knocking down hot beverage, etc).

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.