Re: PT_* vs. struct pt_regs

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

 



Looks like the PT_* offsets are in units of long, but otherwise correct?

Nope, we have PT_D7, but no pt_regs.d7.

If that's all ...

I was trying to define task_thread_info() using TASK_INFO instead of using
struct task_struct directly (cfr. ia64), but these conflicts seem to prevent me
from doing this.

At some time in the past (2.6.13??) I had tried to do something similar
while debugging the Atari interrupt problems (the asm interrupt entries
used wrong offsets to tweak preempt_count() at that time). I gave up in
the end... If I understand Linus' suggestion right, he says we should take
the task struct from the stack instead of going over current (which we
keep in a2, and prefer to use for that reason)?

Yep, that's what he suggests. But we do it differently for `a good reason'.
Unfortunately I don't remember what good reason it was. Yesterday evening I

Because access to current is faster if we always keep it in a register,
that's what I remember. Saves a couple of instructions on context
switches.

searched my lkml archives of 2005 and 2006, but apart from Roman and Al
agreeing we have `a good reason', I couldn't find it.

The decision is much older. Andreas Schwab might remember, as might Roman
Hodek ...

	Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux