From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L0oTQ-00079l-3f for qemu-devel@nongnu.org; Thu, 13 Nov 2008 21:31:52 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L0oTO-000799-18 for qemu-devel@nongnu.org; Thu, 13 Nov 2008 21:31:50 -0500 Received: from [199.232.76.173] (port=33839 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L0oTN-000796-Uu for qemu-devel@nongnu.org; Thu, 13 Nov 2008 21:31:49 -0500 Received: from mail2.shareable.org ([80.68.89.115]:48158) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1L0oTN-0001Ku-Mp for qemu-devel@nongnu.org; Thu, 13 Nov 2008 21:31:49 -0500 Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1L0oTL-0000wi-KU for qemu-devel@nongnu.org; Fri, 14 Nov 2008 02:31:47 +0000 Date: Fri, 14 Nov 2008 02:31:47 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 1/5] Re-factor nic model listing Message-ID: <20081114023147.GF2055@shareable.org> References: <200811131835.08529.paul@codesourcery.com> <491C83EA.9060904@codemonkey.ws> <200811132250.48496.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200811132250.48496.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Paul Brook wrote: > > > On Thursday 13 November 2008, Mark McLoughlin wrote: > > >> .desc = "ARM Versatile/PB (ARM926EJ-S)", > > >> .init = vpb_init, > > >> .use_scsi = 1, > > >> + .nic_models = pci_nic_models, > > > > > > This is wrong, an I'd expect a lot of the other non-PC machines are too. > > > > What's the issue? This board seems to have a PCI bridge attached to it > > so why can't it support any PCI nic? Is this just not something that > > occurs naturally? > > For the same reason you mentioned separately: The abstraction is all wrong. > These boards also support various non-pci NICs. Admittedly this is a > pre-existing bug, but if we're changing things it makes sense to get it > right. Doesn't it make sense to add pci_nic_models _automatically_ to any board with a PCI interface, and have nic_models just for additional NICs which aren't implied by having a PCI interface? -- Jamie