[Top][All Lists]
[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...