RE: A question

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

 



[Resending, I'm not sure where the previous email is lost.]

>From: kernelnewbies-bounce@xxxxxxxxxxxx [mailto:kernelnewbies-bounce@xxxxxxxxxxxx] On Behalf Of hiren panchasara
>Sent: Thursday, September 02, 2010 12:28 PM
>To: Prabhu nath
>Cc: kernelnewbies@xxxxxxxxxxxx; techtraining@xxxxxxxxxxxxxxx
>Subject: Re: A question
>
>Thanks a lot Prabhu for great explanation, comments in-line:
>On Wed, Sep 1, 2010 at 10:02 PM, Prabhu nath <gprabhunath@xxxxxxxxx> wrote:
>Interrupt context is a loaded term. It is used for both top-half and bottom-half processing.
>I need some more reading, will do that :)
>

[Nilesh] Also request you to keep the subject line quite specific. :)

>
>Linux defines two terms in the top-half, one is Interrupt handler (IH) and Interrupt Service Routine (ISR).
>Interrupt handler is a standard kernel code that is executed by the processor once the interrupt is generated. To abstract it, this generic code is executed for all the generated interrupts. This, in general saves the present processor context and paves way for the execution of ISR.
>ISR is a interrupt service routine written by a device driver programmer to handle the interrupt of a device. ISR is mainly responsible to verify the status register of a device to find out the cause of the interrupt and act accordingly.
>
>Both IH and ISR will not have a context of its own. Interrupts generated by a hardware device is asynchronous. i.e. it can be generated at any point in time.
>When such a interrupt is generated, the current execution is interrupted and the execution  control is transferred to IH and ISR will be executed. Thus we can infer that both IH and ISR will be executing in an anonymous context.
>I am struggling to find meaning of interrupt context now.
>

[Nilesh] Context refers to several stuffs that play role in execution . the registers, the stack etc. etc.
http://book.chinaunix.net/special/ebook/Linux_Kernel_Development/0672327201/ch06lev1sec5.html

>
>
>For Eg. Consider there are 3 tasks T2, T3. Suppose T2 invoked a read system call to read data from the secondary media (say hard disk), driver of the hard disk will initiate the device to gather the data and put task T2 in the wait queue and invokes scheduler. Now, scheduler picks up say T3. When processor is executing task T3, there was interrupt generated by the harddisk controller indicating that data is ready. At this point IH and ISR is executed. IH and ISR of this interrupt has no relevance to task T3, but still it is executed in the context of T3. Hence we say that IH and ISR will always be executed in the anonymous context.
>Wow, didnt know this. So IH and ISR wont execute in interrupt context? What is interrupt context then? and if they execute in context of T3, does it have any side-effect on processing of T3?
>

[Nilesh] May be I am not able to completely interpret what is written above. AFAIK, when the task is scheduled out in order to handle interrupt, the stack used is different for the interrupt (current pointer still points to the task_struct of the task, but that.s irrelevant for interrupt). Also the registers are stored (context switch?) when the process is scheduled out. I am not sure how it should run task T3 context. Could someone please clarify?

>
>
>Most of the bottom half execution happens the same way, i.e. it will be executing in the anonymous context unless the job of bottom half is relegated to respective kernel threads. In the latter case the bottom half execution will have its own context.
>
>For more details about top-half and bottom half, refer ULK 3rd edtion by Bovet, Chapter 4
>Would read it.
>
>Thanks again for great insights.
>
>Regards,
>Prabhu

Thanks,
Nilesh
��.n��������+%����w�j)p���{.n����z�ޖw�n'���q���b�������v��m�����Y�����



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux