From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=59907 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOpG7-0004P0-F4 for qemu-devel@nongnu.org; Wed, 16 Jun 2010 05:50:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOpG6-0002O7-68 for qemu-devel@nongnu.org; Wed, 16 Jun 2010 05:50:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40569) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOpG5-0002Ns-V0 for qemu-devel@nongnu.org; Wed, 16 Jun 2010 05:50:10 -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 o5G9o8bc019378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 16 Jun 2010 05:50:08 -0400 Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com [10.35.255.11]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o5G9o779031590 for ; Wed, 16 Jun 2010 05:50:07 -0400 Message-ID: <4C189E4E.5030503@redhat.com> Date: Wed, 16 Jun 2010 12:50:06 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] RFC v2: blockdev_add & friends, brief rationale, QMP docs References: <4C17420E.40601@redhat.com> <4C177581.2040106@redhat.com> <4C1782B8.6050602@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Kevin Wolf , Christoph Hellwig , Gerd Hoffmann , qemu-devel@nongnu.org, Luiz Capitulino On 06/15/2010 05:54 PM, Markus Armbruster wrote: > Avi Kivity writes: > > >> On 06/15/2010 04:27 PM, Markus Armbruster wrote: >> >>> >>>> 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. >>>> >>>> >>> If blockdev_del only ejects media, then we need another command to get >>> rid of a blockdev. >>> >>> >> No. If you have a blockdev just to satisfy the guest device's need >> for a blockdev pointer, you can delete it automatically when the last >> reference goes. >> > That's not how netdev and chardev behave. > Ok. To me duplicate argument lists suggest a lack of orthogonality, though. How about blockdev_add id=... media_attach blockdev=..., media-parameters media_detach blockdev=... blockdev_del id=... So blockdev_add/del define/remove a slot for the media, media_attach/detach connect it to media. >>> Unless you propose that blockdev_del merely ejects media if the blockdev >>> is being used by a device, but destroys the blockdev outright if not. >>> But that would be sick, wouldn't it? >>> >>> >> Create a blockdev implicitly with guest device creation, and use >> blockdev_add (or media_attach) to attach the media. >> >> (but that creates a window where the guest device is visible but media >> is not yet inserted?) >> > Think so, for hot plug. > > Actually, the device model driver would reject an empty blockdev, unless > it's a device with removable media, such as a CD-ROM. > > Having a device with fixed media go through a "no media yet" state > during initialization just complicates things. Defining the media > *before* creating the device is much simpler. > That is true. Maybe we should just ignore the duplication. -- error compiling committee.c: too many arguments to function