From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54442) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UF0x5-0007Tp-Jo for qemu-devel@nongnu.org; Mon, 11 Mar 2013 07:31:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UF0x2-0003i6-DD for qemu-devel@nongnu.org; Mon, 11 Mar 2013 07:31:35 -0400 Received: from mail-lb0-f178.google.com ([209.85.217.178]:47972) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UF0x2-0003hx-4f for qemu-devel@nongnu.org; Mon, 11 Mar 2013 07:31:32 -0400 Received: by mail-lb0-f178.google.com with SMTP id n1so2961839lba.23 for ; Mon, 11 Mar 2013 04:31:31 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1363000640-13398-1-git-send-email-pbonzini@redhat.com> References: <1363000640-13398-1-git-send-email-pbonzini@redhat.com> From: Peter Maydell Date: Mon, 11 Mar 2013 11:31:11 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [RFC] Proposal for hw/ split List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Peter Crosthwaite , qemu-devel@nongnu.org, afaerber@suse.de, agraf@suse.de On 11 March 2013 11:17, Paolo Bonzini wrote: > - Files go in hw/ARCH/ if they used to be in hw/ARCH/Makefile.objs and > they define multiple devices (example: hw/arm/tc6393xb.c) Why are multiple devices in one file a bad thing (or at least, a thing that should determine where a file lives)? Should piix_pci.c move to hw/i386 because it happens to define four devices? Basically I disagree that trying to move more things into hw/$ARCH serves any useful purpose. The split-by-subsystem stuff looks good. > == hw/arm == > hw/a15mpcore.c hw/arm/a15mpcore.c One device. > hw/a9mpcore.c hw/arm/a9mpcore.c One device. > hw/arm11mpcore.c hw/arm/arm11mpcore.c Two devices but I can split them if you insist. > hw/kvm/arm_gic.c hw/arm/kvm/arm_gic.c If we're going to move kvm specific devices out of hw/kvm I'd rather they just went in hw/. It's an implementation detail that a device's back end is KVM specific, so kvm_arm_gic.c should go alongside arm_gic.c. > hw/strongarm.c hw/arm/strongarm.c We could split the individual devices out into files, which would leave sa1110_init() itself (which kind of wants to be a SoC container eventually I guess). > hw/tc6393xb.c hw/arm/tc6393xb.c This is only a single device. (It happens to be a not-converted-to-qdev device.) -- PMM