[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 00/35] hw/ reorganization, part 2
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH 00/35] hw/ reorganization, part 2 |
Date: |
Wed, 20 Mar 2013 01:00:28 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 |
Il 20/03/2013 00:44, Peter Maydell ha scritto:
> On 19 March 2013 23:35, Paolo Bonzini <address@hidden> wrote:
>> > Il 19/03/2013 23:34, Peter Maydell ha scritto:
>>> >> On 19 March 2013 22:23, Paolo Bonzini <address@hidden> wrote:
>>>> >>> So, okay to put these in hw/arm and then I'll work on patches moving
>>>> >>> cpu_arm_init to a*mpcore.c?
>>> >>
>>> >> Wrong way round. If you can't put the cpu_arm_init into the a*mpcore
>>> >> in a way that doesn't make you want to put them in hw/arm/ then
>>> >> it should wait until we've QOMified the CPU cores sufficiently
>>> >> that we can do it properly.
>> >
>> > Does that include calling the CPU constructor something else than
>> > cpu_arm_init (which is defined in target-arm/)? For me that would be
>> > enough to put it in hw/arm.
> The CPU should be created (and thus initialised and realised) the same
> way as any other QOM object or device; the containers shouldn't need
> to call cpu_arm_init directly.
ARM is already quite good in that respect. However, until all
architectures are converted cpu_*_init needs to remain because of
user-mode targets (where the CPUs are created by common code, there is
no board to encapsulate the target-specific differences). IMHO waiting
for the demise of cpu_*_init is putting the cart before the horse, or
another similar proverb.
(Also, I don't see much difference between using a function in
target-ARCH and using a TYPE_FOO define from target-ARCH. They are the
same thing masked through RTTI. hw/ARCH should really be the bridge
between target-ARCH and hw/everything-else, and a*mpcore.c fits in that
description).
Paolo
- Re: [Qemu-devel] [PATCH 00/35] hw/ reorganization, part 2, (continued)
- Re: [Qemu-devel] [PATCH 00/35] hw/ reorganization, part 2, Paolo Bonzini, 2013/03/18
- Re: [Qemu-devel] [PATCH 00/35] hw/ reorganization, part 2, Peter Maydell, 2013/03/18
- Re: [Qemu-devel] [PATCH 00/35] hw/ reorganization, part 2, Paolo Bonzini, 2013/03/19
- Re: [Qemu-devel] [PATCH 00/35] hw/ reorganization, part 2, Peter Maydell, 2013/03/19
- Re: [Qemu-devel] [PATCH 00/35] hw/ reorganization, part 2, Paolo Bonzini, 2013/03/19
- Re: [Qemu-devel] [PATCH 00/35] hw/ reorganization, part 2, Peter Maydell, 2013/03/19
- Re: [Qemu-devel] [PATCH 00/35] hw/ reorganization, part 2, Paolo Bonzini, 2013/03/19
- Re: [Qemu-devel] [PATCH 00/35] hw/ reorganization, part 2, Peter Maydell, 2013/03/19
- Re: [Qemu-devel] [PATCH 00/35] hw/ reorganization, part 2, Paolo Bonzini, 2013/03/19
- Re: [Qemu-devel] [PATCH 00/35] hw/ reorganization, part 2, Peter Maydell, 2013/03/19
- Re: [Qemu-devel] [PATCH 00/35] hw/ reorganization, part 2,
Paolo Bonzini <=
- Re: [Qemu-devel] [PATCH 00/35] hw/ reorganization, part 2, Peter Maydell, 2013/03/20
- Re: [Qemu-devel] [PATCH 00/35] hw/ reorganization, part 2, Paolo Bonzini, 2013/03/20
[Qemu-devel] [PATCH 03/35] configure: fix TPM logic, Paolo Bonzini, 2013/03/18
[Qemu-devel] [PATCH 04/35] tpm: reorganize headers and split hardware part, Paolo Bonzini, 2013/03/18
[Qemu-devel] [PATCH 09/35] hw: make all of hw/usb/ configurable via default-configs/, Paolo Bonzini, 2013/03/18
[Qemu-devel] [PATCH 02/35] hw: make subdirectories for devices, Paolo Bonzini, 2013/03/18
[Qemu-devel] [PATCH 21/35] hw: move char devices to hw/char/, configure via default-configs/, Paolo Bonzini, 2013/03/18