Peter Maydell <peter.mayd...@linaro.org> writes: > On 11 March 2013 11:54, Paolo Bonzini <pbonz...@redhat.com> wrote: >> Il 11/03/2013 12:31, Peter Maydell ha scritto: >>> On 11 March 2013 11:17, Paolo Bonzini <pbonz...@redhat.com> wrote: >>>> hw/arm11mpcore.c hw/arm/arm11mpcore.c >>> >>> Two devices but I can split them if you insist. >> >> These are little more than SoC containers, aren't they? > > They're container devices, yes. But why should container devices > go under hw/$ARCH ? > >>>> 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. >> >> I moved them to hw/ARCH because they really depend on the host kernel. > > That's backwards. To the extent hw/ARCH is anything, it's stuff > specific to guest ARCH, not host ARCH. > > I guess fundamentally my point here is I don't really see why > you're trying to move stuff into hw/ARCH at all. Better to find > a classification scheme that doesn't try to distinguish based > on guest architecture IMHO. > >> Even the very same device might have a different interface on a >> different kernel. But I can certainly move these to hw/SUBSYSTEM/kvm. >> >> (I think you said you disagree, but the next step for me would be to >> move hw/ARCH to target-ARCH/hw). > > Yeah. If nothing else, for practical reasons: Anthony will take > pullreqs for hw/ but not for target-ARCH. Also target-ARCH already > has a nice clean definition of what code goes in it: it's the > code related to emulation of the ARCH CPU. Putting device code > into it would just break that definition for no particularly > obvious reason I can see (whilst also breaking the definition > that devices live under hw/).
Good point. I really, really like separating device models from TCG as clearly as possible.
