[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset
From: |
Andreas Färber |
Subject: |
Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset |
Date: |
Thu, 10 May 2012 23:05:47 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120421 Thunderbird/12.0 |
Am 10.05.2012 22:35, schrieb Peter Maydell:
> On 10 May 2012 01:10, Andreas Färber <address@hidden> wrote:
>> Again, target maintainers are requested to start queuing their patches on
>> their
>> -next branches, where available, to avoid collisions.
>
> Please, if you have patches you want me to put into target-arm.next,
> post them as their own series rather than requiring me to guess
> which ones to pull out of a 74 patch series...
That's quite obvious though, isn't it? The complete v2 (i.e., the
74-patch v2) contains the following patches grouped as ARM devices:
33-37, those clearly labelled as pxa2xx, omap, armv7m, arm_boot:
>> pxa2xx: Use cpu_arm_init() and store ARMCPU
>> omap: Use cpu_arm_init() to store ARMCPU in omap_mpu_state_s
>> armv7m: Use cpu_arm_init() to obtain ARMCPU
>> armv7m: Pass ARMCPU to armv7m_reset()
>> arm_boot: Pass ARMCPU to do_cpu_reset()
> Something this
> big is just too painful to work with.
I don't see your point. Our mailboxes have thousands of messages either
way, you've only been cc'ed on those you are in MAINTAINERS for, and
applying 5 patches from a 74-patch series is not more work than applying
5 patches from a 5-patch series, is it?
This series is put together in such a way that it achieves a goal:
removing cpu_state_reset(). I can send you these and more patches
refactoring ARM devices but then it'll be perceived as "just churn".
74 sounds like much, but the patches are pretty easy to review, no?
These 74 are a subset of a currently 138-patch series and growing -
that's why agreeing on a merge order for qom-next is so important to me.
If I send these out in series of 5 patches and wait for each to get
merged through different trees then by the current rate of applying
this'll take years, especially if we're blocked by unmaintained targets...
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
- [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset, Andreas Färber, 2012/05/09
- [Qemu-devel] [PATCH next v2 04/74] target-i386: Let cpu_x86_init() return X86CPU, Andreas Färber, 2012/05/09
- [Qemu-devel] [PATCH next v2 03/74] target-i386: Pass X86CPU to do_cpu_{init, sipi}(), Andreas Färber, 2012/05/09
- [Qemu-devel] [PATCH next v2 01/74] target-arm: Use cpu_reset() in cpu_arm_init(), Andreas Färber, 2012/05/09
- [Qemu-devel] [PATCH next v2 02/74] target-mips: Use cpu_reset() in cpu_mips_init(), Andreas Färber, 2012/05/09
- Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset, Andreas Färber, 2012/05/10
- Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset, Peter Maydell, 2012/05/10
- Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset,
Andreas Färber <=
- Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset, Max Filippov, 2012/05/14
- Re: [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset, Alexander Graf, 2012/05/21