[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...


SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

reply via email to

[Prev in Thread] Current Thread [Next in Thread]