> **just checking here: LINUX doesnt use a new task for interrupts, it
> just
> executes in the kernel segment using the current tasks context - is
> this
> correct ? - if it is true, then task linking never occurs in LINUX
> which
> answers some of
> my problems !
>
This is correct. Linux does not use interrupt tasks. An interrupt
executes in the
current task's context, possibly switching to the level-0 stack if the
task happened
to run in user-mode (level 3).
> Leading on from this to a more LINUX specific issue, I will present
> what I
> think happens when a timer interrupt occurs and would appreciate any
> corrections that anyone can make:
>
>
> Say a timer interrupt occurs while a user process is executing in user
> mode,
> the timer interrupt handler is invoked (looking at build_timer_irq in
> irq.h), this invokes do_timer still at interrupt level (this is
> slightly
> different to other slow interrupts which re-enable OTHER types of
> interrupt
> before doing do_irq) i.e. no more timer interrupts allowed, which sets
> up
> its bottom half and exits. All interrupts are still disabled while
> build_timer_irq calls ret_from_sys_call. At this point if we
> interrupted
> another interrupt (intr_count!=0) we just iret otherwise the presence
> of
> activated bottom halves is detected and interrupts are re-enabled
> before
> calling handle_bottom_half, this invokes timer_bh (but only if another
> timer
> bottom half hasn't been interrupted (a check in do_bottom_half) - is
> this
> correct ? or is there something else preventing bottom halves from
> being
> re-entered) which is responsible for setting need_resched if quanta
> have
> expired etc. When the bottom half exits back to ret_from_sys_call, we
> check
> to see if we interrupted someone in a system call (iret straight away)
> else
> (interrupted someone in user space) we call schedule() if need_resched
> is
> set which performs the magic JMP tss to switch to a new task. When
> this task
> is re-invoked the last part of schedule() executes and returns us to
> ret_from_sys_call which calls RESTORE_ALL which performs the iret to
> return
> from the original timer interrupt to the user process
>
>
> Somewhere I am getting mixed up with exactly how bottom halves work,
> how do
> they avoid being re-entered (is it like i think ?), can you have more
> than
> one type of bottom half on the active list e.g. 2 timer bottom halves,
> and
> how does
> LINUX ensure that only one bottom half is being executed at a time (in
> the
> presence of other interrupts which call ret_from_sys_call and
> do_bottom_half - it must be to do with intr_count but I dont see where
> the
> bottom half code sets intr_count)...
>
>
> Cheers for any help offered,
>
>
> Mike
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu