Why can"t we sleep in an ISR?

I have a very basic doubt here ... what makes it impossible to sleep
in an ISR? I mean, I know that the kernel preemption is disabled and
the kernel will panic, but I could not understand why?

TIA,

LL
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs

Re: Why can"t we sleep in an ISR?

------=_Part_143789_22170823.1179126614873
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 5/14/07, Learning Linux wrote:
>
> I have a very basic doubt here ... what makes it impossible to sleep
> in an ISR? I mean, I know that the kernel preemption is disabled and
> the kernel will panic, but I could not understand why?


Because the interrupt which you are serving in the ISR has been masked
to avoid preemption(
true for maskable inetrrupts ).Any locks you are holding in ISR are now with
you solely. So, if you try to sleep you take the locks
you untill you are rescheduled and complete. This may lead to a
deadlock for the lock resource.

Thus to avoid this, kernel developers disable preemption and also on every
schedule check if you are *in_interrupt*, if you are, you are probably doing
something really bad.So its better to panic in such case.

This is my naive understanding.
Please CMIIW.

Thanks

TIA,
>
> LL
>
> --
> To unsubscribe from this list: send an email with
> "unsubscribe kernelnewbies" to ecartis@nl.linux.org
> Please read the FAQ at http://kernelnewbies.org/FAQ
>
>


--
play the game

------=_Part_143789_22170823.1179126614873
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Re: Why can"t we sleep in an ISR?

> > I have a very basic doubt here ... what makes it impossible to sleep
> > in an ISR? I mean, I know that the kernel preemption is disabled and
> > the kernel will panic, but I could not understand why?
>
> Because the interrupt which you are serving in the
> ISR has been masked to avoid preemption(
> true for maskable inetrrupts ).Any locks you are holding in ISR are now with
> you solely. So, if you try to sleep you take the locks you untill you are
> rescheduled and complete. This may lead to
> a deadlock for the lock resource.

Ok, but how about an ISR, that does not take any locks? Why can't we
sleep in SUCH an ISR?

AFAIK, taking a lock disables kernel preemption, and hence it is not
allowed to sleep. So I think my question would boil down to why is
sleeping not allowed when the kernel preemption is disabled.

LL
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs

Re: Why can"t we sleep in an ISR?

Learning Linux wrote:
> I have a very basic doubt here ... what makes it impossible to sleep
> in an ISR? I mean, I know that the kernel preemption is disabled and
> the kernel will panic, but I could not understand why?
First: an ISR is meant to be very quick. It is supposed to do only a
minimum of work needed to service the interrupt, then exit.
This is important, as other interrupts might be blocked during your ISR.
Sleeping is out of question, even a long-running loop in no-no.

Second: You don't ever need to sleep in an ISR anyway.
Complicated work that might take time or might need to sleep
is not supposed to be in an ISR. If you think you have a need,
tell us what you're up to and hopefully someone will explain
how do do things properly.

When an interrupt happens that needs complicated servicing, the
ISR don't do the whole job. It just acknowledges the interrupt,
perhaps does a few things with the device in question, then it
exits. It leaves the rest of the work for a bottom half or kernel
thread or something like that. Kernel threads may sleep . . .

Helge Hafting

Re: Why can"t we sleep in an ISR?

------=_Part_147142_10372041.1179147172409
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 5/14/07, Helge Hafting wrote:
>
> Learning Linux wrote:
> > I have a very basic doubt here ... what makes it impossible to sleep
> > in an ISR? I mean, I know that the kernel preemption is disabled and
> > the kernel will panic, but I could not understand why?
> First: an ISR is meant to be very quick. It is supposed to do only a
> minimum of work needed to service the interrupt, then exit.
> This is important, as other interrupts might be blocked during your ISR.
> Sleeping is out of question, even a long-running loop in no-no.
>
> Second: You don't ever need to sleep in an ISR anyway.
> Complicated work that might take time or might need to sleep
> is not supposed to be in an ISR. If you think you have a need,
> tell us what you're up to and hopefully someone will explain
> how do do things properly.
>
> When an interrupt happens that needs complicated servicing, the
> ISR don't do the whole job. It just acknowledges the interrupt,
> perhaps does a few things with the device in question, then it
> exits. It leaves the rest of the work for a bottom half or kernel
> thread or something like that. Kernel threads may sleep . . .


Helge, i think the Original poster wants to know why *exactly*
cannot you sleep?
What prevents me from sleeping?

What is this complicated processing which force an ISR not to sleep?

Thanks

Helge Hafting
>
> --
> To unsubscribe from this list: send an email with
> "unsubscribe kernelnewbies" to ecartis@nl.linux.org
> Please read the FAQ at http://kernelnewbies.org/FAQ
>
>


--
play the game

------=_Part_147142_10372041.1179147172409
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Re: Why can"t we sleep in an ISR?

My understanding is as follows.

Whenever the kernel code sleeps, it means the latest process running
in user space will have to wait for the event on which the kernel code
sleeps.

It makes sense for an exception handler to sleep because an exception
handler always serves the latest process running in user space. So a
process can complain nothing for it having to wait for the event on
which the exception handler in its own context sleeps.

It makes no sense for an ISR to sleep because an ISR does not
necessarily serve the latest process (that is, the interrupted
process). It makes no sense having a process wait for the event having
nothing to do with it.

I could be wrong, so please correct me if the understanding is not right.


2007/5/14, pradeep singh <2500.pradeep@gmail.com>:
>
>
> On 5/14/07, Helge Hafting wrote:
> > Learning Linux wrote:
> > > I have a very basic doubt here ... what makes it impossible to sleep
> > > in an ISR? I mean, I know that the kernel preemption is disabled and
> > > the kernel will panic, but I could not understand why?
> > First: an ISR is meant to be very quick. It is supposed to do only a
> > minimum of work needed to service the interrupt, then exit.
> > This is important, as other interrupts might be blocked during your ISR.
> > Sleeping is out of question, even a long-running loop in no-no.
> >
> > Second: You don't ever need to sleep in an ISR anyway.
> > Complicated work that might take time or might need to sleep
> > is not supposed to be in an ISR. If you think you have a need,
> > tell us what you're up to and hopefully someone will explain
> > how do do things properly.
> >
> > When an interrupt happens that needs complicated servicing, the
> > ISR don't do the whole job. It just acknowledges the interrupt,
> > perhaps does a few things with the device in question, then it
> > exits. It leaves the rest of the work for a bottom half or kernel
> > thread or something like that. Kernel threads may sleep . . .
>
> Helge, i think the Original poster wants to know why
> *exactly* cannot you sleep? What prevents me from
> sleeping?
>
> What is this complicated processing which force an ISR not to sleep?
>
> Thanks
>
> > Helge Hafting
> >
> > --
> > To unsubscribe from this list: send an email with
> > "unsubscribe kernelnewbies" to ecartis@nl.linux.org
> > Please read the FAQ at http://kernelnewbies.org/FAQ
> >
> >
>
>
>
> --
> play the game
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs

Re: Why can"t we sleep in an ISR?

Sleeping in an ISR is not fundamentally impossible - I could design
a multitasker that permitted it - but has significant problems, and
most multitaskers, including Linux, forbid it.

The first problem is the scheduler. "Sleeping" is actually a call
into the scheduler to choose another process to run. There are times -
so-called critical sections - when the scheduler can't be called.

If an interrupt can call the scheduler, then every criticial section
has to disable interrupts. Otherwise, an interrupt might arrive and
end up calling the scheduler. This increases interrupt latency.

If interrupts are forbidden to sleep, then there's no need to
disable interrupts in critical sections, so interrupts can be responded
to faster. Most multitaskers find this worth the price.

The second problem is shared interrupts. You want to sleep until something
happens. The processor hears about that event via an interrupt. Inside
an ISR, interrupts are disabled.

You have to somehow enable the interrupt that will wake up the sleeping
ISR without enabling the interrupt that the ISR is in the middle of handling
(or the handler will start a second time and make a mess).

This is complicated and prone to error. And, in the case of shared interrupts
(as allowed by PCI), it's possible that the the interrupt you need
to wait for is exactly the same interrupt as what you're in the middle
of handling. So it might be impossible!

The third problem is that you're obviously increasing the latency of the
interrupt whose handler you're sleeping in.

Finally, if you're even *thinking* of wanting to sleep in an ISR,
you probably have a deadlock waiting to happen.

Re: Why can"t we sleep in an ISR?

On 5/14/07, Learning Linux wrote:
> Ok, but how about an ISR, that does not take any locks? Why can't we
> sleep in SUCH an ISR?
> LL
> -

The killer reason why you can't sleep in an interrupt is because an
interrupt is not associated with any context in the first place. What
is a context, then? It is the state information for a process. This
includes the kernel and userspace stack pointers, the register set,
and the page tables for that process. The scheduler has access to all
this information, to preempt one process and run another. Contrary to
this, an interrupt, depending on the version of your kernel and arch,
uses a separate irq stack or the kernel stack of the interrupted
process. An irq is not a context but merely a temporary execution to
be concluded asap.

Hope this helps,
Bahadir
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs

Re: Why can"t we sleep in an ISR?

linux@horizon.com wrote:
> Sleeping in an ISR is not fundamentally impossible - I could design
> a multitasker that permitted it - but has significant problems, and
> most multitaskers, including Linux, forbid it.

You could design a system in which most ISRs can sleep,
but even then you'll probably need to make exceptions.

For example, the timer interrupt tends to drive the
scheduler. This means the timer interrupt cannot go
to sleep and expect the scheduler to wake it up at
some point in the future - since there will be no new
timer interrupts to drive the scheduler.

This precludes the timer interrupt from taking certain
sleeping locks, even on a system where interrupts can
sleep (not Linux).

Interrupts will always have some limitations, under
any OS design.

--
All Rights Reversed
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs

Re: Why can"t we sleep in an ISR?

I agree that the reason an interrupt can not sleep is because an
interrupt is not associated with any context. But I do not agree that
it is specifically because the scheduler can not *resume* the context.

In early version, the ISR always borrow the stack of the currently
running process, so if the kernel design had allowed ISR sleep, it
would automatically be able to implement the context switch naturally.
But ISR sleep has been forbidden from the very beginning.

The reason why kernel design does not allow ISR sleep is because a
process should not be forced to wait for a event that irrelative to
itself. When an exception handler sleep, the event it sleeps on is
always in some sense related to the process incurring that exception.
But if an ISR was allowed to sleep, the event it sleeps on would have
nothing to do with the process being interrupted.

So my understanding is, the forbidden of ISR sleep is not because of
the difficulty to resume context, but because a process should not
wait for irrelative event.


2007/5/14, Bahadir Balban :
> On 5/14/07, Learning Linux wrote:
> > Ok, but how about an ISR, that does not take any locks? Why can't we
> > sleep in SUCH an ISR?
> > LL
> > -
>
> The killer reason why you can't sleep in an interrupt is because an
> interrupt is not associated with any context in the first place. What
> is a context, then? It is the state information for a process. This
> includes the kernel and userspace stack pointers, the register set,
> and the page tables for that process. The scheduler has access to all
> this information, to preempt one process and run another. Contrary to
> this, an interrupt, depending on the version of your kernel and arch,
> uses a separate irq stack or the kernel stack of the interrupted
> process. An irq is not a context but merely a temporary execution to
> be concluded asap.
>
> Hope this helps,
> Bahadir
>
> --
> To unsubscribe from this list: send an email with
> "unsubscribe kernelnewbies" to ecartis@nl.linux.org
> Please read the FAQ at http://kernelnewbies.org/FAQ
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs

Re: Why can"t we sleep in an ISR?

------=_Part_157389_2355371.1179206274153
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 5/14/07, Bahadir Balban wrote:
>
> On 5/14/07, Learning Linux wrote:
> > Ok, but how about an ISR, that does not take any locks? Why can't we
> > sleep in SUCH an ISR?
> > LL
> > -
>
> The killer reason why you can't sleep in an interrupt is because an
> interrupt is not associated with any context in the first place.


good enough, but i have a query regarding this then.
On a 8K kernel stack system, doesn't interrupts share the stack associated
with the current process which was interrupted?
Doesn't interrupt steals the CPU slice time allocated to the running process
to run?
Doesn't it run in current process's context ?

What am i missing here?

Thanks
~psr

What
> is a context, then? It is the state information for a process. This
> includes the kernel and userspace stack pointers, the register set,
> and the page tables for that process. The scheduler has access to all
> this information, to preempt one process and run another. Contrary to
> this, an interrupt, depending on the version of your kernel and arch,
> uses a separate irq stack or the kernel stack of the interrupted
> process. An irq is not a context but merely a temporary execution to
> be concluded asap.
>
> Hope this helps,
> Bahadir
>



--
play the game

------=_Part_157389_2355371.1179206274153
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Re: Why can"t we sleep in an ISR?

>
> good enough, but i have a query regarding this then.
> On a 8K kernel stack system, doesn't interrupts share the stack associated
> with the current process which was interrupted?

Yes, I think so.

> Doesn't interrupt steals the CPU slice time allocated to the running process
> to run?

I don't think so but I am not sure.

> Doesn't it run in current process's context ?
>

No. I think the concept of process context is a higher-level logical
concept. Though the interrupt share stack with the interrupted
process, in my opinion it logically does not share the context with
the process.

> What am i missing here?
>
> Thanks
> ~psr
>


But I do not see the exact relationship between your specific queries
and the original question. Could you elaborate?

Re: Why can"t we sleep in an ISR?

------=_Part_158341_13137435.1179213012858
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 5/15/07, Dong Feng wrote:
>
> >
> > good enough, but i have a query regarding this then.
> > On a 8K kernel stack system, doesn't interrupts share the stack
> associated
> > with the current process which was interrupted?
>
> Yes, I think so.
>
> Yes it does.
> > Doesn't interrupt steals the CPU slice time allocated to the running
> process
> > to run?
>
> I don't think so but I am not sure.


Aliter, i think so.How
can an interrupt's execution time go unaccounted then?
I guess it does not, only the current processes running time is accounted
for.
Thoughts?

> Doesn't it run in current process's context ?
> >
>
> No. I think the concept of process context is a higher-level logical
> concept. Though the interrupt share stack with the interrupted
> process, in my opinion it logically does not share the context with
> the process.


Yes, you are right as i can infer. thats why ISRs are special kernel
control paths.
But the poster asked, why can't we make ISRs to share context with the
interrupted process if
it not holding any locks? This is rather a desing issues IMO rather
than imlementation, isnt it?


I guess even if it is possible, it would over complicate the handler code.
Better trying to keep it simple i guess. Please CMIIW

[snip]
>
> But I do not see the exact relationship between your specific queries
> and the original question. Could you elaborate?


My query here was related to your previous reply.Just wanted to pit some doubts
as raised by the orirignal poster.That's it.

Thank you
~psr




--
play the game

------=_Part_158341_13137435.1179213012858
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Re: Why can"t we sleep in an ISR?

> >
> > I don't think so but I am not sure.
>
> Aliter, i think so.How can an interrupt's execution time go
> unaccounted then?
> I guess it does not, only the current processes running
> time is accounted for.
> Thoughts?
>

The interrupt handler's execution time will definitely defer the
execution of the process, but I think it does not steal the process's
time slice (the time_slice field not subtracted).

> > > Doesn't it run in current process's context ?
> > >
> >
> > No. I think the concept of process context is a higher-level logical
> > concept. Though the interrupt share stack with the interrupted
> > process, in my opinion it logically does not share the context with
> > the process.
>
> Yes, you are right as i can infer. thats why ISRs
> are special kernel control paths.
> But the poster asked, why can't we make ISRs to
> share context with the interrupted process
> if
> it not holding any locks? This is rather a desing issues
> IMO rather than imlementation, isnt it?
>
> I guess even if it is possible, it would over complicate the handler code.
> Better trying to keep it simple i guess. Please CMIIW

My understanding is, the ISR is in different context from the process
because of the definition of term *context*. In my opinion, to say two
code pieces running in the same context means that two pieces of code
has some logical relationship to meet a common objective. That's why I
said *context* is a higher-level logical concept. It's not a concept
defined in the level of hardware or code implementation, but instead
in the level of logical. I think, by its definition, it makes no sense
to say an ISR share context with the process interrupted by it because
an ISR just randomly interrupts a process, with no logical
relationship.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs

Re: Why can"t we sleep in an ISR?

------=_Part_158813_5644331.1179216752720
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 5/15/07, Dong Feng wrote:
>
> > >
> > > I don't think so but I am not sure.
> >
> > Aliter, i think so.How can an interrupt's execution time go
> > unaccounted then?
> > I guess it does not, only the current processes running
> > time is accounted for.
> > Thoughts?
> >
>
> The interrupt handler's execution time will definitely defer the
> execution of the process, but I think it does not steal the process's
> time slice (the time_slice field not subtracted).


Ok, if i accept this, how does that explains this-

Following code snippet is from main schedule() function[kernel 2.6.20.1] -

now = sched_clock();
if(likely((long long)(now - prev->timestamp) < NS_MAX_SLEEP_AVG)) {
run_time = now - prev->timestamp;
/* blah blah */
} else
run_time = NS_MAX_SLEEP_AVG;

Now,
AFAIK runtime = now - prev->timestamp; will get you a value which (
prev->timestamp is *stamped* during previous
switching of the tasks) is difference of this previous stamp and now value.
Assuming before this schedule() an interrupt was served, then where did the
time spent in ISR accounting is adjusted? I guess this is the code, where
it is checking for a *possible* runtime to overshoot its stipulated
NS_MAX_SLEEP_AVG and resetting this. Isn't it?
And exactly why would that happen?
Perhaps because the process was about to expire its slice when somebody
barged in and stole its share and also overshot the stipulated time(may be
very less though).

Can you help me in clearing this?

> > > Doesn't it run in current process's context ?
> > > >
> > >
> > > No. I think the concept of process context is a higher-level logical
> > > concept. Though the interrupt share stack with the interrupted
> > > process, in my opinion it logically does not share the context with
> > > the process.
> >
> > Yes, you are right as i can infer. thats why ISRs
> > are special kernel control paths.
> > But the poster asked, why can't we make ISRs to
> > share context with the interrupted process
> > if
> > it not holding any locks? This is rather a desing issues
> > IMO rather than imlementation, isnt it?
> >
> > I guess even if it is possible, it would over complicate the handler
> code.
> > Better trying to keep it simple i guess. Please CMIIW
>
> My understanding is, the ISR is in different context from the process
> because of the definition of term *context*. In my opinion, to say two
> code pieces running in the same context means that two pieces of code
> has some logical relationship to meet a common objective. That's why I
> said *context* is a higher-level logical concept. It's not a concept
> defined in the level of hardware or code implementation, but instead
> in the level of logical. I think, by its definition, it makes no sense
> to say an ISR share context with the process interrupted by it because
> an ISR just randomly interrupts a process, with no logical
> relationship.


Right agreed.

Thanks
~psr


--
play the game

------=_Part_158813_5644331.1179216752720
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Re: Why can"t we sleep in an ISR?

> The interrupt handler's execution time will definitely defer the
> execution of the process, but I think it does not steal the process's
> time slice (the time_slice field not subtracted).

It will definitely be substracted from the process's time slice.
Because the timeslice is substracted in timer interrupt, and does not
differenciate if the process is executing ISR or not.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs

Re: Why can"t we sleep in an ISR?

Yes, you are right in this regard. An interrupt handler does steal the
time slice from the interrupted process.

So now I think it is considered an acceptable deviation in calculating
the process run time as well as determine process scheduling because
an ISR should take very short time to return, in part as a consequence
of the rule that ISR should not sleep.


2007/5/15, Learning Linux :
> > The interrupt handler's execution time will definitely defer the
> > execution of the process, but I think it does not steal the process's
> > time slice (the time_slice field not subtracted).
>
> It will definitely be substracted from the process's time slice.
> Because the timeslice is substracted in timer interrupt, and does not
> differenciate if the process is executing ISR or not.
>
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs

Re: Why can"t we sleep in an ISR?

This is a multipart mime message


--Next_1179221663---0-202.54.124.237-1119
Content-type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

=0AOn Tue, 15 May 2007 pradeep singh wrote :=0A>On 5/14/07, Bahadir=
Balban wrote:=0A>>=0A>>On 5/14/07, Learning Lin=
ux wrote:=0A>> > Ok, but how about an ISR, that =
does not take any locks? Why can't we=0A>> > sleep in SUCH an ISR?=0A>> > L=
L=0A>> > -=0A>>=0A>>The killer reason why you can't sleep in an interrupt i=
s because an=0A>>interrupt is not associated with any context in the first =
place.=0A>=0A>=0A>good enough, but i have a query regarding this then.=0A>O=
n a 8K kernel stack system, doesn't interrupts share the stack associated=
=0A>with the current process which was interrupted?=0AYes, you are right.=
=0A>Doesn't interrupt steals the CPU slice time allocated to the running pr=
ocess=0A>to run?=0AYes=0A>Doesn't it run in current process's context ?=0AY=
ou got it worng here. It runs on behalf of the process, but in the current =
process's context. =0AFor interrupts we have a dirrerent context altogether=
..=0A>=0A>What am i missing here?=0AThere are two different contexts of exec=
ution=0AProcess context=0AInterrupt context=0A>=0A>Thanks=0A>~psr=0A>=0ATha=
nks,=0A-Rohit=0A>What=0A>>is a context, then? It is the state information f=
or a process. This=0A>>includes the kernel and userspace stack pointers, th=
e register set,=0A>>and the page tables for that process. The scheduler has=
access to all=0A>>this information, to preempt one process and run another=
.. Contrary to=0A>>this, an interrupt, depending on the version of your kern=
el and arch,=0A>>uses a separate irq stack or the kernel stack of the inter=
rupted=0A>>process. An irq is not a context but merely a temporary executio=
n to=0A>>be concluded asap.=0A>>=0A>>Hope this helps,=0A>>Bahadir=0A>>=0A>=
=0A>=0A>=0A>-- play the game=0A
--Next_1179221663---0-202.54.124.237-1119
Content-type: text/html;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

=0A 
=0A
=0A
=0AOn Tue, 15 May 2007 pradeep singh wrote :=

=0A>On 5/14/07, Bahadir Balban <bahadir.balban@gmail.com> wrot=
e:
=0A>>
=0A>>On 5/14/07, Learning Linux <learninglinu=
x4@gmail.com> wrote:
=0A>> > Ok, but how about an ISR, that =
does not take any locks? Why can't we
=0A>> > sleep in SUCH an =
ISR?
=0A>> > LL
=0A>> > -
=0A>>
=0A>=
>The killer reason why you can't sleep in an interrupt is because an
=
=0A>>interrupt is not associated with any context in the first place.=

=0A>
=0A>
=0A>good enough, but i have a query regarding =
this then.
=0A>On a 8K kernel stack system, doesn't interrupts share =
the stack associated
=0A>with the current process which was interrupt=
ed?
=0AYes, you are right.
=0A>Doesn't interrupt steals the CPU sl=
ice time allocated to the running process
=0A>to run?
=0AYes
=
=0A>Doesn't it run in current process's context ?
=0AYou got it worng=
here. It runs on behalf of the process, but in the current process's conte=
xt.
=0AFor interrupts we have a dirrerent context altogether.
=0A>=
;
=0A>What am i missing here?
=0AThere are two different contexts =
of execution
=0AProcess context
=0AInterrupt context
=0A>
=
=0A>Thanks
=0A>~psr
=0A>
=0AThanks,
=0A-Rohit
=0A&g=
t;What
=0A>>is a context, then? It is the state information for a =
process. This
=0A>>includes the kernel and userspace stack pointer=
s, the register set,
=0A>>and the page tables for that process. Th=
e scheduler has access to all
=0A>>this information, to preempt on=
e process and run another. Contrary to
=0A>>this, an interrupt, de=
pending on the version of your kernel and arch,
=0A>>uses a separa=
te irq stack or the kernel stack of the interrupted
=0A>>process. =
An irq is not a context but merely a temporary execution to
=0A>>b=
e concluded asap.
=0A>>
=0A>>Hope this helps,
=0A>&=
gt;Bahadir
=0A>>
=0A>
=0A>
=0A>
=0A>-- pla=
y the game

bin/AdWorks/click.cgi/www.rediff.com/signature-home.htm/1050 715198@Middle5/= 1177315_1171298/1176420/1?PARTNER=3D3&OAS_QUERY=3Dnull target=3Dnew '> src =3Dhttp://imadworks.rediff.com/cgi-bin/AdWorks/adimage.cgi/1 177315_1171= 298/creative_1176420.gif alt=3D'Peanuts' border=3D0>

Re: Why can"t we sleep in an ISR?

------=_Part_159383_12638171.1179222407269
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 15 May 2007 09:34:23 -0000, rohit hooda
wrote:
>
>
>
>
> On Tue, 15 May 2007 pradeep singh wrote :
> >On 5/14/07, Bahadir Balban wrote:
> >>
> >>On 5/14/07, Learning Linux wrote:
> >> > Ok, but how about an ISR, that does not take any locks? Why can't we
> >> > sleep in SUCH an ISR?
> >> > LL
> >> > -
> >>
> >>The killer reason why you can't sleep in an interrupt is because an
> >>interrupt is not associated with any context in the first place.
> >
> >
> >good enough, but i have a query regarding this then.
> >On a 8K kernel stack system, doesn't interrupts share the stack
> associated
> >with the current process which was interrupted?
> Yes, you are right.
> >Doesn't interrupt steals the CPU slice time allocated to the running
> process
> >to run?
> Yes
> >Doesn't it run in current process's context ?
> You got it worng here. It runs on behalf of the process, but in the
> current process's context.
> For interrupts we have a dirrerent context altogether.
>
Ok, that explains a bit.
how will you define an interrupt context?

Thanks
~psr

>
> >What am i missing here?
> There are two different contexts of execution
> Process context
> Interrupt context
> >
> >Thanks
> >~psr
> >
> Thanks,
> -Rohit
> >What
> >>is a context, then? It is the state information for a process. This
> >>includes the kernel and userspace stack pointers, the register set,
> >>and the page tables for that process. The scheduler has access to all
> >>this information, to preempt one process and run another. Contrary to
> >>this, an interrupt, depending on the version of your kernel and arch,
> >>uses a separate irq stack or the kernel stack of the interrupted
> >>process. An irq is not a context but merely a temporary execution to
> >>be concluded asap.
> >>
> >>Hope this helps,
> >>Bahadir
> >>
> >
> >
> >
> >-- play the game
>
>
> [image: Peanuts]




--
play the game

------=_Part_159383_12638171.1179222407269
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Re: Why can"t we sleep in an ISR?

Dong Feng wrote:
>> Doesn't it run in current process's context ?
>>
>
> No. I think the concept of process context is a higher-level logical
> concept. Though the interrupt share stack with the interrupted
> process, in my opinion it logically does not share the context with
> the process.

No, the term context here has a specific meaning. It refers to those
things which flow from the current pointer, including the virtual memory
space, file descriptor table, current uid, and so forth. Because the
current pointer is not changed on entry to an ISR, the ISR is executing
in the context of the interrupted process, and thus uses that process'
virtual memory, etc.

Re: Why can"t we sleep in an ISR?

2007/5/16, Phillip Susi :
> Dong Feng wrote:
> >> Doesn't it run in current process's context ?
> >>
> >
> > No. I think the concept of process context is a higher-level logical
> > concept. Though the interrupt share stack with the interrupted
> > process, in my opinion it logically does not share the context with
> > the process.
>
> No, the term context here has a specific meaning. It refers to those
> things which flow from the current pointer, including the virtual memory
> space, file descriptor table, current uid, and so forth. Because the
> current pointer is not changed on entry to an ISR, the ISR is executing
> in the context of the interrupted process, and thus uses that process'
> virtual memory, etc.
>

If what you say were true, then an ISR would be running in the same
context as the interrupted process. But please check any article or
book, it will say ISR running in different context from any process.
So ISR is considered in its own context, although it shares a lot of
things with the interrupted process. I would only say *context* is a
higher-level logical concept.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs

Re: Why can"t we sleep in an ISR?

Dong Feng wrote:
> If what you say were true, then an ISR would be running in the same
> context as the interrupted process.

Yes, and it is, as others have said in this thread, which is a good
reason why ISRs can't sleep.

> But please check any article or
> book, it will say ISR running in different context from any process.
> So ISR is considered in its own context, although it shares a lot of
> things with the interrupted process. I would only say *context* is a
> higher-level logical concept.

Depends on which book or article you are reading I suppose. The
generally accepted and often used thought is that ISRs technically are
running in the context of the interrupted process, but because that
context is unknown and therefore should not be used, it is often said
that they run in no context, or outside of any context. Sometimes
people then assume that because they run outside of any ( particular )
process context, they must be in their own context, but this is a mistake.


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs

Re: Why can"t we sleep in an ISR?

OK. I think the gap between you and me is the definition of term
*context*. If you go to Linux Kernel Development, 2nd Edition (ISBN
0-672-32720-1), Page 6, then you will read the following:

..... in Linux, ... each processor is doing one of three things at any
given moment:

1. In kernel-space, in process context, ...
2. In kernel-space, in interrupt context, not associated with a process, ...
3. In user-space ...

This list is inclusive. ...


Maybe you prefer other terminology system, but I do like the above
definition given by Robert Love. So maybe in your system *context*
mean something at hardware level and you say ISR is in process
context, but I think it is more like a logical level and agree with
Rovert's definition.

And in hardware level, Robert's *context* definition also mean
something specific, that I started to be aware of. That is, *in the
same context* means a kernel-code is triggered by a user-space code.
*in different context* means a kernel-code is triggered by an external
interrupt source other than a user-space code.

Context has nothing to do with whether an ISR borrow any data
structure of a process, instead, its something logical or related to
causality.



2007/5/16, Phillip Susi :
> Dong Feng wrote:
> > If what you say were true, then an ISR would be running in the same
> > context as the interrupted process.
>
> Yes, and it is, as others have said in this thread, which is a good
> reason why ISRs can't sleep.
>
> > But please check any article or
> > book, it will say ISR running in different context from any process.
> > So ISR is considered in its own context, although it shares a lot of
> > things with the interrupted process. I would only say *context* is a
> > higher-level logical concept.
>
> Depends on which book or article you are reading I suppose. The
> generally accepted and often used thought is that ISRs technically are
> running in the context of the interrupted process, but because that
> context is unknown and therefore should not be used, it is often said
> that they run in no context, or outside of any context. Sometimes
> people then assume that because they run outside of any ( particular )
> process context, they must be in their own context, but this is a mistake.
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs

Re: Why can"t we sleep in an ISR?

Dong Feng wrote:
> OK. I think the gap between you and me is the definition of term
> *context*. If you go to Linux Kernel Development, 2nd Edition (ISBN
> 0-672-32720-1), Page 6, then you will read the following:
>
> .... in Linux, ... each processor is doing one of three things at any
> given moment:
>
> 1. In kernel-space, in process context, ...
> 2. In kernel-space, in interrupt context, not associated with a process,
> ...
> 3. In user-space ...
>
> This list is inclusive. ...

Yep, I disagree with that use of the term, because it is misleading and
caused your confusion. The context that the ISR executes in is not
associated with a _known_ process is more correct.

> Maybe you prefer other terminology system, but I do like the above
> definition given by Robert Love. So maybe in your system *context*
> mean something at hardware level and you say ISR is in process
> context, but I think it is more like a logical level and agree with
> Rovert's definition.
>
> And in hardware level, Robert's *context* definition also mean
> something specific, that I started to be aware of. That is, *in the
> same context* means a kernel-code is triggered by a user-space code.
> *in different context* means a kernel-code is triggered by an external
> interrupt source other than a user-space code.

Right, and that becomes more clear when you say that the ISR's is
executing in an indeterminate process context, rather than saying it
does not have any context at all, or has its own special context.

> Context has nothing to do with whether an ISR borrow any data
> structure of a process, instead, its something logical or related to
> causality.

No, it has everything to do with the data structures of the process.
When you are executing "in the same context" as you put it, as called
from the user mode code, you know you are using the task structure of
that process and so you can make use of that structure. For example,
you can look at the current uid to decide if you should allow an
operation to proceed. When you are in an ISR, there _is_ a task
structure there, but you shouldn't use it because you don't know which
task structure it is because you don't know which task you are
interrupting. Thus if you look at the current uid in an ISR, you have
no idea what you will see there and it will change from interrupt to
interrupt, depending on which task gets interrupted.


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs

Re: Why can"t we sleep in an ISR?

Hi, Phillip,

I have said the gap between you and me is the definition of context.
In Robert's definition, *context* is used in a classification method
and really something in higher-level. And I used that term to explain
why ISR can not sleep.

If you do not like the name, name it your way and substitute term
*context* in my previous mail with what you name. But I believe my
other explaination still hold, right?

And again, if anyway I am forced to use your termnology system, I
would also agree your other point regarding hardware.


2007/5/18, Phillip Susi :
> Dong Feng wrote:
> > OK. I think the gap between you and me is the definition of term
> > *context*. If you go to Linux Kernel Development, 2nd Edition (ISBN
> > 0-672-32720-1), Page 6, then you will read the following:
> >
> > .... in Linux, ... each processor is doing one of three things at any
> > given moment:
> >
> > 1. In kernel-space, in process context, ...
> > 2. In kernel-space, in interrupt context, not associated with a process,
> > ...
> > 3. In user-space ...
> >
> > This list is inclusive. ...
>
> Yep, I disagree with that use of the term, because it is misleading and
> caused your confusion. The context that the ISR executes in is not
> associated with a _known_ process is more correct.
>
> > Maybe you prefer other terminology system, but I do like the above
> > definition given by Robert Love. So maybe in your system *context*
> > mean something at hardware level and you say ISR is in process
> > context, but I think it is more like a logical level and agree with
> > Rovert's definition.
> >
> > And in hardware level, Robert's *context* definition also mean
> > something specific, that I started to be aware of. That is, *in the
> > same context* means a kernel-code is triggered by a user-space code.
> > *in different context* means a kernel-code is triggered by an external
> > interrupt source other than a user-space code.
>
> Right, and that becomes more clear when you say that the ISR's is
> executing in an indeterminate process context, rather than saying it
> does not have any context at all, or has its own special context.
>
> > Context has nothing to do with whether an ISR borrow any data
> > structure of a process, instead, its something logical or related to
> > causality.
>
> No, it has everything to do with the data structures of the process.
> When you are executing "in the same context" as you put it, as called
> from the user mode code, you know you are using the task structure of
> that process and so you can make use of that structure. For example,
> you can look at the current uid to decide if you should allow an
> operation to proceed. When you are in an ISR, there _is_ a task
> structure there, but you shouldn't use it because you don't know which
> task structure it is because you don't know which task you are
> interrupting. Thus if you look at the current uid in an ISR, you have
> no idea what you will see there and it will change from interrupt to
> interrupt, depending on which task gets interrupted.
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs

Re: Re: Why can"t we sleep in an ISR?

T24gNS8xOC8wNywg6ZmI5rabIDxlYXN0YWdlQGNvc2hpcC5jb20+IHdyb3Rl Ogo+IERlYXIgYWxs
Ogo+ICAgICAgICAgQXMgeW91IGJvdGggYWdyZWUgdGhhdCBhbiBJU1IgY2Fu bid0IGJlIGFzbGVl
cCBpbiBhbiBpbnRlcnJ1cHQgQ09OVEVYVCwKPiBpdCByZW1pbmQgbWUgb2Yg YW5vdGhlciBxdWVz
dGlvbiBhcyBiZWxvdy4KPiAgICAgICAgIENhbiBhIHN5c3RlbSB0aW1lciB0 aWNrIElTUiBzY2hl
ZHVsZSB1c2VyIHByb2Nlc3NlcyBpbiBuZXN0ZWQgaW50ZXJydXB0IENPTlRF WFQ/CkkgZG8gbm90
IHRoaW5rIHNvLiBzeXN0ZW0gdGljayBJU1IgZG9lcyBub3Qgc2NoZWR1bGVz IGRpcmVjdGx5IGFu
eQpwcm9jZXNzIGZvciB0aGF0IG1hdHRlci5Pbmx5IHRoaW5nIGl0IGNhbiBh bmQgcGVyaGFwcyBh
bnlvdGhlciBwcm9jZXNzCmNhbiBkbyBpcyByZXF1ZXN0IHRoZSBzY2hlZHVs ZXIgdG8gc2NoZWR1
bGUgYSBwcm9jZXNzIG9yIGl0c2VsZiBieQpjaGFuZ2luZyB0aGUgc3RhdGUu ClRoZSBtb21lbnQg
c2NoZWR1bGVyIHNlZXMgaXQsIGl0IG1heSBydW4gdGhlIHByb2Nlc3MuCgo+ ICAgICAgICAgSSB0
aGluayB3aGVuIGhhcmR3YXJlIHRpbWVyIHRpY2sgaW50ZXJydXB0IGZpcmVz IGluIG5vbiBuZXN0
ZWQgaW50ZXJydXB0IENPTlRFWFQsCj4gaXRzIHJlbGF0ZWQgSVNSIHdpbGwg c2NoZWR1bGUgdXNl
ciBwcm9jZXNzZXMgYW5kIGFsc28gY2xlYXIgc3RhY2sgZGF0YShjb250YWlu aW5nIFNTIENTIEVG
TEFHIElQLGV0YyxpbiBYODYgc3lzdGVtKQo+IGluIGtlcm5lbCBzdGFjayBz dG9yZWQgaW4gd2hl
biB0aW1lciB0aWNrIElTUiBmaXJlcy4KQXBvbG9naWVzIEkgYW0gbm90IGFi bGUgdG8gdW5kZXJz
dGFuZCB3aGF0IHlvdSBhcmUgc2F5aW5nLCBzb3JyeSA6LSgKClRoYW5rcwp+ cHNyCj4gICAgICAg
ICBEb2VzIHRoaXMgbWVhbiB0aGUgdGltZXIgdGljayBJU1Igc29tZXRpbWVz IGNhbm5vdCBkaXJl
Y3RseSByZXR1cm4gdG8gdGhlIHByb2Nlc3MgQ09OVEVYVAo+IHdoaWNoIGlu dGVycnVwdGVkIGJ5
IHRoZSB0aW1lciB0aWNrIElTUj8KPgo+IEhpLCBQaGlsbGlwLAo+Cj4gSSBo YXZlIHNhaWQgdGhl
IGdhcCBiZXR3ZWVuIHlvdSBhbmQgbWUgaXMgdGhlIGRlZmluaXRpb24gb2Yg Y29udGV4dC4KPiBJ
biBSb2JlcnQncyBkZWZpbml0aW9uLCAqY29udGV4dCogaXMgdXNlZCBpbiBh IGNsYXNzaWZpY2F0
aW9uIG1ldGhvZAo+IGFuZCByZWFsbHkgc29tZXRoaW5nIGluIGhpZ2hlci1s ZXZlbC4gQW5kIEkg
dXNlZCB0aGF0IHRlcm0gdG8gZXhwbGFpbgo+IHdoeSBJU1IgY2FuIG5vdCBz bGVlcC4KPgo+IElm
IHlvdSBkbyBub3QgbGlrZSB0aGUgbmFtZSwgbmFtZSBpdCB5b3VyIHdheSBh bmQgc3Vic3RpdHV0
ZSB0ZXJtCj4gKmNvbnRleHQqIGluIG15IHByZXZpb3VzIG1haWwgd2l0aCB3 aGF0IHlvdSBuYW1l
LiBCdXQgSSBiZWxpZXZlIG15Cj4gb3RoZXIgZXhwbGFpbmF0aW9uIHN0aWxs IGhvbGQsIHJpZ2h0
Pwo+Cj4gQW5kIGFnYWluLCBpZiBhbnl3YXkgSSBhbSBmb3JjZWQgdG8gdXNl IHlvdXIgdGVybW5v
bG9neSBzeXN0ZW0sIEkKPiB3b3VsZCBhbHNvIGFncmVlIHlvdXIgb3RoZXIg cG9pbnQgcmVnYXJk
aW5nIGhhcmR3YXJlLgo+Cj4KPiAyMDA3LzUvMTgsIFBoaWxsaXAgU3VzaSA8 cHN1c2lAY2ZsLnJy
LmNvbT46Cj4gPiBEb25nIEZlbmcgd3JvdGU6Cj4gPiA+IE9LLiBJIHRoaW5r IHRoZSBnYXAgYmV0
d2VlbiB5b3UgYW5kIG1lIGlzIHRoZSBkZWZpbml0aW9uIG9mIHRlcm0KPiA+ ID4gKmNvbnRleHQq
LiBJZiB5b3UgZ28gdG8gTGludXggS2VybmVsIERldmVsb3BtZW50LCAybmQg RWRpdGlvbiAoSVNC
Tgo+ID4gPiAwLTY3Mi0zMjcyMC0xKSwgUGFnZSA2LCB0aGVuIHlvdSB3aWxs IHJlYWQgdGhlIGZv
bGxvd2luZzoKPiA+ID4KPiA+ID4gLi4uLiAgaW4gTGludXgsIC4uLiBlYWNo IHByb2Nlc3NvciBp
cyBkb2luZyBvbmUgb2YgdGhyZWUgdGhpbmdzIGF0IGFueQo+ID4gPiBnaXZl biBtb21lbnQ6Cj4g
PiA+Cj4gPiA+IDEuIEluIGtlcm5lbC1zcGFjZSwgaW4gcHJvY2VzcyBjb250 ZXh0LCAuLi4KPiA+
ID4gMi4gSW4ga2VybmVsLXNwYWNlLCBpbiBpbnRlcnJ1cHQgY29udGV4dCwg bm90IGFzc29jaWF0
ZWQgd2l0aCBhIHByb2Nlc3MsCj4gPiA+IC4uLgo+ID4gPiAzLiBJbiB1c2Vy LXNwYWNlIC4uLgo+
ID4gPgo+ID4gPiBUaGlzIGxpc3QgaXMgaW5jbHVzaXZlLiAuLi4KPiA+Cj4g PiBZZXAsIEkgZGlz
YWdyZWUgd2l0aCB0aGF0IHVzZSBvZiB0aGUgdGVybSwgYmVjYXVzZSBpdCBp cyBtaXNsZWFkaW5n
IGFuZAo+ID4gY2F1c2VkIHlvdXIgY29uZnVzaW9uLiAgVGhlIGNvbnRleHQg dGhhdCB0aGUgSVNS
IGV4ZWN1dGVzIGluIGlzIG5vdAo+ID4gYXNzb2NpYXRlZCB3aXRoIGEgX2tu b3duXyBwcm9jZXNz
IGlzIG1vcmUgY29ycmVjdC4KPiA+Cj4gPiA+IE1heWJlIHlvdSBwcmVmZXIg b3RoZXIgdGVybWlu
b2xvZ3kgc3lzdGVtLCBidXQgSSBkbyBsaWtlIHRoZSBhYm92ZQo+ID4gPiBk ZWZpbml0aW9uIGdp
dmVuIGJ5IFJvYmVydCBMb3ZlLiBTbyBtYXliZSBpbiB5b3VyIHN5c3RlbSAq Y29udGV4dCoKPiA+
ID4gbWVhbiBzb21ldGhpbmcgYXQgaGFyZHdhcmUgbGV2ZWwgYW5kIHlvdSBz YXkgSVNSIGlzIGlu
IHByb2Nlc3MKPiA+ID4gY29udGV4dCwgYnV0IEkgdGhpbmsgaXQgaXMgbW9y ZSBsaWtlIGEgbG9n
aWNhbCBsZXZlbCBhbmQgYWdyZWUgd2l0aAo+ID4gPiBSb3ZlcnQncyBkZWZp bml0aW9uLgo+ID4g
Pgo+ID4gPiBBbmQgaW4gaGFyZHdhcmUgbGV2ZWwsIFJvYmVydCdzICpjb250 ZXh0KiBkZWZpbml0
aW9uIGFsc28gbWVhbgo+ID4gPiBzb21ldGhpbmcgc3BlY2lmaWMsIHRoYXQg SSBzdGFydGVkIHRv
IGJlIGF3YXJlIG9mLiBUaGF0IGlzLCAqaW4gdGhlCj4gPiA+IHNhbWUgY29u dGV4dCogbWVhbnMg
YSBrZXJuZWwtY29kZSBpcyB0cmlnZ2VyZWQgYnkgYSB1c2VyLXNwYWNlIGNv ZGUuCj4gPiA+ICpp
biBkaWZmZXJlbnQgY29udGV4dCogbWVhbnMgYSBrZXJuZWwtY29kZSBpcyB0 cmlnZ2VyZWQgYnkg
YW4gZXh0ZXJuYWwKPiA+ID4gaW50ZXJydXB0IHNvdXJjZSBvdGhlciB0aGFu IGEgdXNlci1zcGFj
ZSBjb2RlLgo+ID4KPiA+IFJpZ2h0LCBhbmQgdGhhdCBiZWNvbWVzIG1vcmUg Y2xlYXIgd2hlbiB5
b3Ugc2F5IHRoYXQgdGhlIElTUidzIGlzCj4gPiBleGVjdXRpbmcgaW4gYW4g aW5kZXRlcm1pbmF0
ZSBwcm9jZXNzIGNvbnRleHQsIHJhdGhlciB0aGFuIHNheWluZyBpdAo+ID4g ZG9lcyBub3QgaGF2
ZSBhbnkgY29udGV4dCBhdCBhbGwsIG9yIGhhcyBpdHMgb3duIHNwZWNpYWwg Y29udGV4dC4KPiA+
Cj4gPiA+IENvbnRleHQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB3aGV0aGVy IGFuIElTUiBib3Jy
b3cgYW55IGRhdGEKPiA+ID4gc3RydWN0dXJlIG9mIGEgcHJvY2VzcywgaW5z dGVhZCwgaXRzIHNv
bWV0aGluZyBsb2dpY2FsIG9yIHJlbGF0ZWQgdG8KPiA+ID4gY2F1c2FsaXR5 Lgo+ID4KPiA+IE5v
LCBpdCBoYXMgZXZlcnl0aGluZyB0byBkbyB3aXRoIHRoZSBkYXRhIHN0cnVj dHVyZXMgb2YgdGhl
IHByb2Nlc3MuCj4gPiBXaGVuIHlvdSBhcmUgZXhlY3V0aW5nICJpbiB0aGUg c2FtZSBjb250ZXh0
IiBhcyB5b3UgcHV0IGl0LCBhcyBjYWxsZWQKPiA+IGZyb20gdGhlIHVzZXIg bW9kZSBjb2RlLCB5
b3Uga25vdyB5b3UgYXJlIHVzaW5nIHRoZSB0YXNrIHN0cnVjdHVyZSBvZgo+ ID4gdGhhdCBwcm9j
ZXNzIGFuZCBzbyB5b3UgY2FuIG1ha2UgdXNlIG9mIHRoYXQgc3RydWN0dXJl LiAgRm9yIGV4YW1w
bGUsCj4gPiB5b3UgY2FuIGxvb2sgYXQgdGhlIGN1cnJlbnQgdWlkIHRvIGRl Y2lkZSBpZiB5b3Ug
c2hvdWxkIGFsbG93IGFuCj4gPiBvcGVyYXRpb24gdG8gcHJvY2VlZC4gIFdo ZW4geW91IGFyZSBp
biBhbiBJU1IsIHRoZXJlIF9pc18gYSB0YXNrCj4gPiBzdHJ1Y3R1cmUgdGhl cmUsIGJ1dCB5b3Ug
c2hvdWxkbid0IHVzZSBpdCBiZWNhdXNlIHlvdSBkb24ndCBrbm93IHdoaWNo Cj4gPiB0YXNrIHN0
cnVjdHVyZSBpdCBpcyBiZWNhdXNlIHlvdSBkb24ndCBrbm93IHdoaWNoIHRh c2sgeW91IGFyZQo+
ID4gaW50ZXJydXB0aW5nLiAgVGh1cyBpZiB5b3UgbG9vayBhdCB0aGUgY3Vy cmVudCB1aWQgaW4g
YW4gSVNSLCB5b3UgaGF2ZQo+ID4gbm8gaWRlYSB3aGF0IHlvdSB3aWxsIHNl ZSB0aGVyZSBhbmQg
aXQgd2lsbCBjaGFuZ2UgZnJvbSBpbnRlcnJ1cHQgdG8KPiA+IGludGVycnVw dCwgZGVwZW5kaW5n
IG9uIHdoaWNoIHRhc2sgZ2V0cyBpbnRlcnJ1cHRlZC4KPiA+Cj4gPgo+ID4K PiAtCj4gVG8gdW5z
dWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxpbmUgInVuc3Vi c2NyaWJlIGxpbnV4
LW5ld2JpZSIgaW4KPiB0aGUgYm9keSBvZiBhIG1lc3NhZ2UgdG8gbWFqb3Jk b21vQHZnZXIua2Vy
bmVsLm9yZwo+IE1vcmUgbWFqb3Jkb21vIGluZm8gYXQgIGh0dHA6Ly92Z2Vy Lmtlcm5lbC5vcmcv
bWFqb3Jkb21vLWluZm8uaHRtbAo+IFBsZWFzZSByZWFkIHRoZSBGQVEgYXQg aHR0cDovL3d3dy5s
aW51eC1sZWFybi5vcmcvZmFxcwo+Cj4KPgo+Cj4KPiAqKioqKirlo7DmmI4q KioqKioKPiDmnKzp
gq7ku7blj4rlhbbpmYTku7bmiYDljIXlkKvnmoTkv6Hmga/lnYflsZ7mt7Hl nLPluILlkIzmtLLn
lLXlrZDogqHku73mnInpmZDlhazlj7jllYbkuJrnp5jlr4bvvIzku4XpmZDk uo7mjIflrprnmoTk
uKrkurrmiJbnu4Tnu4fkvb/nlKjvvIzmnKrnu4/orrjlj6/vvIzkuI3lvpfm s4TpnLLnu5nku7vk
vZXnrKzkuInmlrnjgILlpoLmnpzmgqjkuI3mmK/mnKzpgq7ku7bnmoTpooTm nJ/mlLbku7bkurrv
vIzor7fnq4vljbPlsIbmraTplJnor6/lkYrnn6XmnKzlj5Hku7bkurrvvIzl ubbov4XpgJ/msLjk
uYXmgKfliKDpmaTmnKzpgq7ku7blj4rpmYTku7bnmoTmiYDmnInljp/lp4vk u7bjgIHlpI3liLbk
u7blkozovpPlh7rku7bvvIzor7fli7/kv53lrZjjgIHlpI3liLbjgIHliKnn lKjlkozms4TpnLLm
nKzpgq7ku7blj4rpmYTku7bnmoTku7vkvZXlhoXlrrnvvIzku6Xnoa7kv53m gqjml6DpobvkuLrm
raTmib/mi4Xms5XlvovotKPku7vjgILosKLosKLmgqjnmoTlkIjkvZzvvIEK PiAqKioqKipOT1RJ
Q0UqKioqKioKPiBUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0 ZWQgd2l0aCBpdCBt
YXkgY29udGFpbiBsZWdhbGx5IFBSSVZJTEVHRUQgYW5kL29yIENPTkZJREVO VElBTCBJTkZPUk1B
VElPTiwgYW5kIGFyZSBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBwZXJzb25h bCB1c2Ugb2YgdGhl
IHJlY2lwaWVudChzKSBuYW1lZCBhYm92ZS4gV2l0aG91dCBwcmlvciBjb25z ZW50LCB5b3Ugc2hv
dWxkIG5vdCBkaXNzZW1pbmF0ZSB0aGlzIGNvbW11bmljYXRpb24gdG8gYW55 IGlycmVsZXZhbnQg
cGFydHku44CASWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0 aW9uIGluIGVycm9y
LCBwbGVhc2UgaW1tZWRpYXRlbHkgbm90aWZ5IHRoaXMgc2VuZGVyIGFuZCBw ZXJtYW5lbnRseSBk
ZWxldGUgdGhlIG9yaWdpbmFsICYgZHVwbGljYXRlIGNvcHksIGFuZCBhbnkg cHJpbnRvdXQgdGhl
cmVvZi4gQW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5 aW5nIG9mIHRoaXMg
Y29tbXVuaWNhdGlvbiBpcyBTVFJJQ1RMWSBQUk9ISUJJVEVELiBUaGFuayB5 b3UhCj4KPgo+Cj4K
CgotLSAKcGxheSB0aGUgZ2FtZQo=

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ