From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH 4/4] pci: add pci test device Date: Wed, 03 Apr 2013 17:46:00 +0200 Message-ID: <515C4EB8.8090602@redhat.com> References: <20130403102229.GD18179@redhat.com> <515C037E.5030706@redhat.com> <20130403103301.GG18179@redhat.com> <515C05B0.2000401@redhat.com> <20130403103846.GB18725@redhat.com> <515C1719.903@redhat.com> <20130403120041.GA22200@redhat.com> <515C1B0C.3070505@redhat.com> <20130403140648.GC22200@redhat.com> <515C37ED.1070104@redhat.com> <20130403142804.GA23848@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, gleb@redhat.com, mtosatti@redhat.com To: "Michael S. Tsirkin" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:37356 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758296Ab3DCPqH (ORCPT ); Wed, 3 Apr 2013 11:46:07 -0400 In-Reply-To: <20130403142804.GA23848@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Il 03/04/2013 16:28, Michael S. Tsirkin ha scritto: > > You need to group similar devices for the nesting to be useful. For > > example, it should be easy to check if something is true of all ISA > > bridges, or to do the same change in all of them. ISA and PCI bridges > > have too little in common for that (and why not put I2C and SPI in > > hw/bridge too :)). > > Yes, why not. What all bridges need to share is their modeling > needs to be similar. That's one thing that practically > needs to be cleaned up I think. Bridges are simply devices that expose their own bus, or that derive from a class that does. But bridge is not a universal word, some buses use controller or adapter, it would be weird to have hw/bridge/i2c or hw/bridge/scsi (and leave two files only in hw/scsi). > But will this conflict with how libhw works at the moment? > We don't want to rebuild pci for each target ... No, we won't. In fact, almost everything should be built once only. As far as PCI is concerned, if it's not it is because of some really bad hacks. For unmaintained boards, it's best to stash them in hw/ARCH. If we limit the amount of files that are built per-target, it works nicely. Paolo