[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] Proposal for hw/ split
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [RFC] Proposal for hw/ split |
Date: |
Mon, 11 Mar 2013 13:44:37 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 |
Il 11/03/2013 13:39, Peter Maydell ha scritto:
> 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 ?
Because they don't really implement any logic, ideally a board should be
a little more than a bunch of container devices. And boards 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.
For KVM guest == host, so you cannot reuse them for any other
architectures. But if there's disagreement, leaving them in hw/kvm/ is
the best thing to do.
Paolo
Re: [Qemu-devel] [RFC] Proposal for hw/ split, Edgar E. Iglesias, 2013/03/11
Re: [Qemu-devel] [RFC] Proposal for hw/ split, Stefan Hajnoczi, 2013/03/11
Re: [Qemu-devel] [RFC] Proposal for hw/ split, Richard Henderson, 2013/03/12