From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45652) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TswiZ-0006JQ-CZ for qemu-devel@nongnu.org; Wed, 09 Jan 2013 09:33:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TswiY-0001Q7-7v for qemu-devel@nongnu.org; Wed, 09 Jan 2013 09:33:23 -0500 Received: from mail-la0-f41.google.com ([209.85.215.41]:44738) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TswiX-0001Q3-UE for qemu-devel@nongnu.org; Wed, 09 Jan 2013 09:33:22 -0500 Received: by mail-la0-f41.google.com with SMTP id em20so1932526lab.28 for ; Wed, 09 Jan 2013 06:33:20 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <50ED2E2F.2090301@greensocs.com> References: <1357584074-10852-1-git-send-email-fred.konrad@greensocs.com> <1357584074-10852-5-git-send-email-fred.konrad@greensocs.com> <50ED2E2F.2090301@greensocs.com> From: Peter Maydell Date: Wed, 9 Jan 2013 14:33:00 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 04/61] virtio-pci : refactor virtio-pci device. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?S09OUkFEIEZyw6lkw6lyaWM=?= Cc: kwolf@redhat.com, aliguori@us.ibm.com, e.voevodin@samsung.com, mst@redhat.com, mark.burton@greensocs.com, qemu-devel@nongnu.org, agraf@suse.de, cornelia.huck@de.ibm.com, aneesh.kumar@linux.vnet.ibm.com, stefanha@redhat.com, amit.shah@redhat.com, pbonzini@redhat.com, afaerber@suse.de On 9 January 2013 08:45, KONRAD Fr=C3=A9d=C3=A9ric wrote: > On 08/01/2013 18:54, Peter Maydell wrote: >> This doesn't have any code in it yet (it gets added in later patches) bu= t >> the final result looks very repetitive. I think you'd be better off just >> having >> some arrays: >> >> uint16_t virtio_pci_device_id[] =3D { >> [VIRTIO_ID_BLOCK] =3D PCI_DEVICE_ID_VIRTIO_BLOCK, >> [VIRTIO_ID_NET] =3D PCI_DEVICE_ID_VIRTIO_NET, >> (etc) >> }; >> >> similarly for the class. Then you can just drop the switch statement. >> >> In fact I think you might as well put in the array entries for all >> the virtio devices in this patch rather than adding one in each of the >> "add virtio-foo device" patches; it will do no harm for them to be >> there early and it makes the later patches a little smaller. > > And what happen when it is a bad ID ? Error, same as before. Obviously you protect the array lookup with a sizeof check for out of range, and you know if the array entry is 0 it's invalid (0 being neither a valid device id or class). If you think that looks too ugly then you could keep the switch, but don't put calls to pci_config_set_device_id() and pci_config_set_class() in each switch, that's just code duplication. -- PMM