From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46408) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFnfa-000896-3F for qemu-devel@nongnu.org; Wed, 13 Mar 2013 11:32:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UFnfT-0006NO-Ae for qemu-devel@nongnu.org; Wed, 13 Mar 2013 11:32:46 -0400 Received: from greensocs.com ([87.106.252.221]:57153 helo=s15328186.onlinehome-server.info) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFnfT-0006N9-1A for qemu-devel@nongnu.org; Wed, 13 Mar 2013 11:32:39 -0400 Message-ID: <51409C0F.4000007@greensocs.com> Date: Wed, 13 Mar 2013 16:32:31 +0100 From: =?UTF-8?B?S09OUkFEIEZyw6lkw6lyaWM=?= MIME-Version: 1.0 References: <1363080131-16427-1-git-send-email-fred.konrad@greensocs.com> <1363080131-16427-3-git-send-email-fred.konrad@greensocs.com> <513F3DAF.8050405@greensocs.com> <513F44E7.2020306@greensocs.com> <513F482E.1000106@greensocs.com> <20130312173102.3e86ef76@gondolin> <514037CA.1010607@greensocs.com> In-Reply-To: <514037CA.1010607@greensocs.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v6 2/8] virtio-blk: add the virtio-blk device. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck Cc: Kevin Wolf , Peter Maydell , aliguori@us.ibm.com, mst@redhat.com, mark.burton@greensocs.com, qemu-devel@nongnu.org, Stefan Hajnoczi , afaerber@suse.de On 13/03/2013 09:24, KONRAD Fr=C3=A9d=C3=A9ric wrote: > On 12/03/2013 17:31, Cornelia Huck wrote: >> On Tue, 12 Mar 2013 16:22:22 +0100 >> KONRAD Fr=C3=A9d=C3=A9ric wrote: >> >>> On 12/03/2013 16:12, Peter Maydell wrote: >>>> On 12 March 2013 15:08, KONRAD Fr=C3=A9d=C3=A9ric =20 >>>> wrote: >>>>> On 12/03/2013 15:42, Peter Maydell wrote: >>>>>> Yes, I see your problem there, but DEFINE_VIRTIO_BLK_SCSI_PROPERTY >>>>>> and DEFINE_DATA_PLANE_PROPERTIES are just convenience macros, not >>>>>> ones that are expected to be used by other code, right? So you can >>>>>> define them with commas (and name them something so it's obvious >>>>>> they're not intended for wider use as property array elements), >>>>>> and then just make sure your public-facing=20 >>>>>> DEFINE_VIRTIO_BLK_PROPERTIES >>>>>> doesn't end with a comma. (You can do that by putting the macros >>>>>> that expand to maybe-comma-or-not at the front, not the end.) >>>>>> >>>>>> -- PMM >>>>> ok, I can put a comment which say not to use them? >>>> And suitable macro names (ie not ones which look like all >>>> the other DEFINE_FOO_PROPERTIES ones). Alternatively since the >>>> macro's only used once as far as I can see, you could just not >>>> bother to abstract it out. The virtio-ccw blk properties still >>>> just have inline #ifdefs for the scsi prop for instance. >>>> >>>> -- PMM >>> The macro is used for virtio-blk device and virtio-blk-pci. >>> s390x devices don't use the same properties. >>> >> Looking at the s390 devices, the difference seems to be the following: >> >> - CHS - missing on virtio-ccw, I'll do a patch. >> - config_wce - missing on s390-virtio and virtio-ccw, should probably >> be added. >> - x-data-plane - we plan to add this eventually to virtio-ccw, but not >> to s390-virtio. Could that be split out from the generic properties= ? >> > ok, so what I can do is: > > - split up x-data-plane property (so it will be only in virtio-pci.c). > - fix this comma thing. > > Then when you put these two missing properties you can just replace=20 > all of them > with the macro. > > Is that ok for everybody? Peter? Stefan? > Any other suggestion? Thanks, Fred