From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NdNwg-00070u-6g
	for qemu-devel@nongnu.org; Fri, 05 Feb 2010 08:10:02 -0500
Received: from [199.232.76.173] (port=56008 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NdNwf-00070m-M1
	for qemu-devel@nongnu.org; Fri, 05 Feb 2010 08:10:01 -0500
Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim
	4.60) (envelope-from <hch@lst.de>) id 1NdNwe-0002Jv-7U
	for qemu-devel@nongnu.org; Fri, 05 Feb 2010 08:10:01 -0500
Received: from verein.lst.de ([213.95.11.210]:60950)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60)
	(envelope-from <hch@lst.de>) id 1NdNwd-0002JZ-Qs
	for qemu-devel@nongnu.org; Fri, 05 Feb 2010 08:10:00 -0500
Date: Fri, 5 Feb 2010 14:09:56 +0100
From: Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] [PATCH 2/4] block: add block topology options
Message-ID: <20100205130956.GA17475@lst.de>
References: <20100129190417.GA25237@lst.de> <20100129190440.GA25287@lst.de>
	<4B69C7DF.9000900@codemonkey.ws>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4B69C7DF.9000900@codemonkey.ws>
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.gnu.org/pipermail/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: Anthony Liguori <anthony@codemonkey.ws>
Cc: Christoph Hellwig <hch@lst.de>, "Martin K. Petersen" <martin.petersen@oracle.com>, qemu-devel@nongnu.org

On Wed, Feb 03, 2010 at 01:00:47PM -0600, Anthony Liguori wrote:
> But I don't think this is the wrong place to do it.  The 
> BlockDriverState reflects that backing device, not the emulated device 
> itself.  In this case, you're trying to set a property of the emulated 
> device.

I think that's very borderline.  While the emulated device exposes these
properties, they are in fact a property of the backing storage, the
right sector and min/max I/O sizes are determined by the backing storage
device.

> I think these need to be qdev properties of the respective devices.  
> From a UI perspective, you can still expose -drive options for the end 
> user to consume, but this data should be associated with the devices 
> themselves.

In addition to not really beeing more logical this would be a lot more
effort.  We'd need to add properties to all the device, which means
including dealing with the n+1 ide variants, the virtio-pci proxy, etc.

If you believe it really needs to be in the qdev properties I'll
implement it, but I suspect the current version is a better idea.