lkml.org 
[lkml]   [2003]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: top stack (l)users for 2.5.69
On Wed, 7 May 2003 16:42:26 -0400, Timothy Miller wrote:
> Richard B. Johnson wrote:
> >
> >When a caller executes int 0x80, this is a software interrupt,
> >called a 'trap'. It enters the trap handler on the kernel stack,
> >with the segment selectors set up as defined for that trap-handler.
> >It happens because software told hardware what to do ahead of time.
> >Software doesn't do it during the trap event. In the trap handler,
> >no context switch normally occurs.
>
> On typical processors, when one gets an interrupt, the current program
> counter and processor state flags are pushed onto a stack. Which stack
> gets used for this?

I have no idea, what a 'typical processor' might look like. But the
thing most CPU seem to have in common is that they save two registers
either on the stack or into other registers that only exist for this
purpose (SRR on PPC).

Once that has happened, the OS has the job to figure out where it's
stack (or equivalent) is located, *without* clobbering the registers.
Once that is done, it can save all the registern on the stack,
including SRR. It might also move what the CPU has pushed to the
"stack" somewhere else.

After the interrupt has been handled, the reverse path is executed,
restoring registers in the correct order, possibly switching from
kernel to user stack, etc.

And there is one kernel stack per process. Please don't argue about
that, unless you have read the code.

Jörn

--
Do not stop an army on its way home.
-- Sun Tzu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:35    [W:0.953 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site