Re: [Qemu-devel] [RFC] Proposal for hw/ split

[Markus Armbruster]

Peter Maydell <address@hidden> writes:

> On 11 March 2013 11:54, Paolo Bonzini <address@hidden> wrote:
>> Il 11/03/2013 12:31, Peter Maydell ha scritto:
>>> On 11 March 2013 11:17, Paolo Bonzini <address@hidden> 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.