Re: [PATCH v2] powerpc: Add irqtrace support for 32-bit powerpc

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> Right, it's not needed on 4xx/BookE, but I didn't think it worth
> optimizing at this point, since it will split the code into 4xx/BookE
> and classic versions. Let's get it working solid first.

Yup, it's just that I spotted it while reading the code.

> That's what I originally thought and had in my first version.
> However, in the BookE case, we must save at least r3, r4, and r5.
> (See data_access: in head_fsl_booke.S.)  It isn't clear what the
> rules are, and I didn't want to set a trap for when a handler is
> added that uses a fourth argument.

Ok, this definitely is worth some rework around the edges. For now, I
suppose keeping it stable will do.

> If you think it's worth it, I could test a version that saves
> r3, r4, and r5 and restores the others from ptregs.

Don't bother for now. I'll see if we can do things differently later.

> > Also, only the system call really cares about -restoring- them. Maybe
> > you could stick that in an ifdef CONFIG_TRACE_IRQFLAGS section in
> > DoSyscall pulling them back off the ptregs in the stackframe. 
> 
> Another optimization that I'm not convinced is worth the trouble
> for this tracing code.  I'll try to take a look at it though.
> As you say below, it's scary code.

Yup. The RESTOREALL case doesn't write the result to the PT_REGS but I'm
not yet sure if that's a big issue to do it regardless or not.

Ben.