From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=39889 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OJ35k-0008S8-Uv
	for qemu-devel@nongnu.org; Mon, 31 May 2010 07:23:37 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1OJ35j-0003DB-Pf
	for qemu-devel@nongnu.org; Mon, 31 May 2010 07:23:36 -0400
Received: from mx1.redhat.com ([209.132.183.28]:4324)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1OJ35j-0003Cy-JA
	for qemu-devel@nongnu.org; Mon, 31 May 2010 07:23:35 -0400
Received: from int-mx04.intmail.prod.int.phx2.redhat.com
	(int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17])
	by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o4VBNXTt007322
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <qemu-devel@nongnu.org>; Mon, 31 May 2010 07:23:33 -0400
Message-ID: <4C039C2F.1070106@redhat.com>
Date: Mon, 31 May 2010 14:23:27 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <m34ohryjib.fsf@blackfin.pond.sub.org> <4C022B59.80109@redhat.com>
	<m3typo4a07.fsf@blackfin.pond.sub.org>
In-Reply-To: <m3typo4a07.fsf@blackfin.pond.sub.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: RFC: blockdev_add & friends, brief rationale,
	QMP docs
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Markus Armbruster <armbru@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>, qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@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.