在 2013-04-24三的 16:22 +0200，Andreas Färber写道：
> Am 24.04.2013 09:40, schrieb li guang:
> > 在 2013-04-24三的 08:36 +0100，Peter Maydell写道：
> >> On 24 April 2013 08:32, li guang <lig.f...@cn.fujitsu.com> wrote:
> >>> I think even others want to use something like you said,
> >>> it should not 'cs_base', or, it's a bad name.
> >>
> >> Yes, this is why I said "has a less than helpful name".
> >>
> >>>>
> >>>>>>> --- a/target-sparc/cpu.h
> >>>>>>> +++ b/target-sparc/cpu.h
> >>>>>>> @@ -715,7 +715,7 @@ trap_state* cpu_tsptr(CPUSPARCState* env);
> >>>>>>> #define TB_FLAG_AM_ENABLED (1 << 5)
> >>>>>>>
> >>>>>>> static inline void cpu_get_tb_cpu_state(CPUSPARCState *env,
> >>>>>>> target_ulong *pc,
> >>>>>>> - target_ulong *cs_base, int
> >>>>>>> *flags)
> >>>>>>> + int *flags)
> >>>>>>> {
> >>>>>>> *pc = env->pc;
> >>>>>>> *cs_base = env->npc;
> >>
> >>>> You clearly have a problem with your compile and test
> >>>> process then, because it is clear from the patch that
> >>>> you've removed the cs_base argument from this function
> >>>> but the function still has a use of 'cs_base' in it.
> >>>
> >>> ???, sorry, where do I miss 'cs_base' removing?
> >>
> >> Last quoted line of source: "*cs_base = env->npc".
> >
> > OK, thanks!
> > that remove by overshoot script!
>
> Some general reminders:
>
> We're in Soft Freeze, so in general no new big patch series will go into
> 1.5 unless there's a maintainer willing to take care of it - for i386
> there is none, and random code cleanups do not look like something we
> must absolutely have in the release last minute. At least no one brought
> up on yesterday's call that this is a must-have, so maybe after the
> release would be a better time to let people review this?
>
> Whenever you send more than one patch, please include a cover letter.
>
> When you resend a series modified, please include a version such as v2,
> v3, etc. and a change log in the cover letter rather than resending with
> [updated] or in a way that can't be distinguished at all.
>
> You're expected to assure that your patches compile and don't break
> `make check` at least. Repeatedly sending patches that cannot possibly
> build okay means you're either overlooking error output from your build
> or maybe building the wrong source directory?
>
> Generally, touching the innards of TCG requires a good code
> understanding and testing of multiple targets; personally I try to avoid
> unnecessary changes for fear of breaking rare corner cases. ;)
>
OK, I will, Thanks!
