[Autogenerated] Here.
Is the conceptual view of how interrupts get dispatched.
Let's say I have some code running.
That code could be running in user mode or kernel mode doesn't
really matter because when an interrupt comes in,
it has nothing.
To do with the currently executing code So suppose we have a thread,
that issued some IOP operation at that point,
that thread could go into a weight, state,
and the IPO operation, is Now in progress,
and the IP can run different code at some point.
The request finishes on the hardware level.
And the disk, drive raises an interrupt,
and this is when that particular code has been interrupted.
And that code belongs to some other process,
some other thread, that has nothing.
To do with the original call this is why an interact, is a synchrony.
When it occurs,
it means nothing about the currently executing code So
obviously the first thing we need to do is to save the state
of the currently executing thread.
So, that when the interrupt handling, is done,
it can resume to the previous code the previous state
as though nothing has happened.
So there's some trap frame which is an internal data structure that's being
used in order to save the state of the thread on its kernel stack and then
There's something that happens which I'll discuss,
in the Next few videos which is related to masking off other
inter apps that have lower priorities.
And these priorities, are known as I R Q L s which we'll discuss very soon.
But let's just disregard that for now.
The appropriate inter up service routine,
is retrieved from the inter app dispatch table based on the vector
number provided by the inter app controller,
and then the appropriate interrupt, service routine,
is invoked, doing whatever it needs.
To do We'll discuss some of the aspects of a typical interrupt, service routine.
Later on in this module Once it's done, we need to restore the C P U state.
So that the original thread can continue running
from where its its left off notice.
In this case, what we have is the fact, that the thread,
whatever that threat may be is the one being interrupted.
And its going to be tasked with running that interrupt,
service routine there, is no special thread out there.
To perform that kind of role,
which essentially means that Any threat can run any interrupt.
Service routine, that thread, of course has nothing.
To do with the interrupt at all, but it happens.
To run on that processor, that was chosen,
to handle, that interrupt at that point in time.
So on the one hand, it's not its fault.
On the other hand, someone has to run the interrupt, service routine.
So you might be worried about the the scheduling aspect of the thread.
Does it get charged for that time running the internet app service routine,
and the answer, is in this case, no.
So that kind of time.
Is not deducted from its time slice, its quantum that It's allowed.
To run this time.
That is used to run the inter up service routine, is on the house sort of thing.
So, that nobody.
Is really charged with that uh the threat, is not being punished for it.
However,
it does get slightly delayed because it has to run
that inter up up service routine.
Let's see the inter, up dispatch table in a kernel debugger