Re: [PATCH 1/2] GDB process record and reverse debugging improvements for arm*-linux*

[Omair Javaid <omair.javaid@linaro.org>]

On Thu 28 Nov 2013 05:19:15 PM PKT, Yao Qi wrote:
> On 11/28/2013 06:04 AM, Omair Javaid wrote:
>>> gdb is for user space; and use space is not allowed to use SPSR
>>>> directly using MSR instruction.
>>>> so old code base + new code base whereever we have got SPSR getting
>>>> modified we need to remove the same.
>>>>
>> I agree with you that we have to do a lot of rework of previous process record code. But I am not sure it would be productive for us to get working code out and loose the functionality or delay its submission. As Record/Replay is pretty much functional with this set of patches I am hoping that we can do a complete rework if required later on.
>>
>
> If there is something broken related to the submissions, the common
> practise could be one of them below:
>
>   1. Fix them first,
>   2. Document the existing limitations/problems or write a test case to
> kfail it.  In this way, people are aware of this.
>   3. Continue the submission and revisit the problems later.
>
> Personally, I choose one of them, depending on the complexity of fixing
> the existing problems.  This patch series is a large one, and based on
> some existing code.  I would like to fix existing problems first, before
> doing something new, if it doesn't take much time on fixing existing
> problems.  These patches are preparatory, and usually simple.  so they
> have more chances to be reviewed in a timely manner.  These preparatory
> patches set up a context for your large patch series, and the context is
> helpful to understanding your patch series.  As a result, the review
> process may be shortened.
>
> I don't want you to fix existing problems first, or take other actions.
> Just let you know something submitters can do to help maintainers to
> approve patches.
>

Ping! Looking for maintainer's approval for arm process record/replay 
improvement patches.