qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] qemu linux-user/qemu.h linux-user/signal.c linu...


From: Jocelyn Mayer
Subject: Re: [Qemu-devel] qemu linux-user/qemu.h linux-user/signal.c linu...
Date: Thu, 27 Sep 2007 18:41:51 +0200

On Thu, 2007-09-27 at 09:53 -0600, Thayne Harbaugh wrote:
> On Thu, 2007-09-27 at 16:08 +0200, Jocelyn Mayer wrote:
> > On Thu, 2007-09-27 at 13:57 +0000, Thiemo Seufer wrote:
> > > CVSROOT:  /sources/qemu
> > > Module name:      qemu
> > > Changes by:       Thiemo Seufer <ths>     07/09/27 13:57:58
> > > 
> > > Modified files:
> > >   linux-user     : qemu.h signal.c syscall.c 
> > >   target-alpha   : cpu.h 
> > >   target-arm     : cpu.h 
> > >   target-i386    : cpu.h 
> > >   target-mips    : cpu.h 
> > >   target-ppc     : cpu.h 
> > 
> >  static inline target_ulong get_sp_from_cpustate(CPUPPCState *state)
> > {
> >   return state->gpr[1];
> > }
> > 
> > This is no way related to CPU emulation then has nothing to do in cpu.h.
> > Furthermore, there no notion of sigaltstack or even stack pointer in the
> > PowerPC specification.
> > Revert this patch immediatly, please, and stop breaking others code...
> 
> My apologies.  I put get_sp_from_cpustate() in cpu.h because it is a
> generic function that isn't exclusive to sigaltstack().  If it's
> preferred it can be exclusive to sigaltstack().
> 
> > How should we say "don't do weird things in others code" ??? Again, and
> > again and again...
> 
> My hope was that these types of comments would be made prior to the
> patch being committed.  Is there a developer document that describes the
> intentions of code layout, design philosophy, etc. so that I'm not
> guessing?

Then, I'm sorry, I did not notice this when you submitted your patch.
And I even did not imagine that it could touch anything out of
linux-user. Please apologize, I've been reading your submission too
fast, not being directly interressed by the patch...

> Please send me additional comments so that I can rework the patch for
> resubmission.

I don't know in which header you should define those ABI specific stuff.
Maybe a header may be added in the linux-user target subdirectories for
those kind of definitions; it may help avoiding too many #ifdef
everywhere...






reply via email to

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