From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=54838 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OOVUc-0004nN-4s
	for qemu-devel@nongnu.org; Tue, 15 Jun 2010 08:43:51 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1OOVUa-0006qj-KV
	for qemu-devel@nongnu.org; Tue, 15 Jun 2010 08:43:49 -0400
Received: from mx1.redhat.com ([209.132.183.28]:26307)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1OOVUa-0006qV-7a
	for qemu-devel@nongnu.org; Tue, 15 Jun 2010 08:43:48 -0400
Received: from int-mx03.intmail.prod.int.phx2.redhat.com
	(int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16])
	by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o5FChl5o026771
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <qemu-devel@nongnu.org>; Tue, 15 Jun 2010 08:43:47 -0400
Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com
	[10.35.255.11])
	by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id o5FChkOo000432
	for <qemu-devel@nongnu.org>; Tue, 15 Jun 2010 08:43:46 -0400
Message-ID: <4C177581.2040106@redhat.com>
Date: Tue, 15 Jun 2010 15:43:45 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] RFC v2: blockdev_add & friends, brief rationale,
	QMP docs
References: <m3iq5qye65.fsf@blackfin.pond.sub.org> <4C17420E.40601@redhat.com>
	<m3hbl4scwl.fsf@blackfin.pond.sub.org>
In-Reply-To: <m3hbl4scwl.fsf@blackfin.pond.sub.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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>, Christoph Hellwig <chellwig@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>, qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>

On 06/15/2010 03:23 PM, Markus Armbruster wrote:
>
>> media_insert/remove seem to duplicate blockdev_add/del.  Perhaps we
>> don't need them?
>>
>> To change media, tell the guest device to eject, blockdev_del,
>> blockdev_add, reassociate the guest and host parts.
>>      
> Device model code is not prepared to have host parts go away and come
> back during operation.  The device model driver attaches to the host
> part on initialization, and detaches only when the device gets destroyed
> (hot unplug).
>
> If we yank out the host part during operation as you propose, then the
> device model driver's pointer to the host part becomes null.  I don't
> see that ending happily.
>    

I'm only talking about the interface, not the implementation.  Internal 
design details shouldn't be exposed.

For the implementation, I imagine you can create an empty blockdev 
during guest device creation and treat blockdev_add/blockdev_del as 
media change/eject.

>> To pretend you're a media changer, blockdev_add all your cds at once
>> and just change the guest/host association when you want to hear a new
>> band.
>>
>> For a fake a multipath setup, blockdev_add one device, associate it
>> with multiple guest interfaces.
>>
>> Otherwise, looks good.
>>      
> Any preference on the command line option syntax?
>    

Something incredibly long and complicated?

We might keep the existing stuff which is already complicated enough for 
users, and ask machines to build guests using QMP instead of the command 
line.

-- 
error compiling committee.c: too many arguments to function