we know, a kernel task could be preemptived in 2.6, but i'm not sure
that does a ISR routine could be preemptived in 2.6.
any one have practice with this problem? thanks for hare the
description on it.
Printable View
we know, a kernel task could be preemptived in 2.6, but i'm not sure
that does a ISR routine could be preemptived in 2.6.
any one have practice with this problem? thanks for hare the
description on it.
lion3875 <lion3875@gmail.com> wrote:[color=blue]
> we know, a kernel task could be preemptived in 2.6, but i'm not sure
> that does a ISR routine could be preemptived in 2.6.
>
> any one have practice with this problem? thanks for hare the
> description on it.[/color]
I'm no expert on kernel internals, but my guess (without checking) would be
the ISR would need to be atomic.
Otherwise, if an interrupt could interrupt the interrupt service routine
causing the interrupt service routine to run again...
Well, everything would get very messy very quickly.
It might end up spending all its time attempting to service interrupts but
not actually get a chance to complete any of them.
--
| |What to do if you find yourself stuck in a crack|
| [email]spike1@freenet.co.uk[/email] |in the ground beneath a giant boulder, which you|
| |can't move, with no hope of rescue. |
| Andrew Halliwell BSc |Consider how lucky you are that life has been |
| in |good to you so far... |
| Computer Science | -The BOOK, Hitch-hiker's guide to the galaxy.|
After takin' a swig o' grog, Andrew Halliwell belched out
this bit o' wisdom:
[color=blue]
> lion3875 <lion3875@gmail.com> wrote:[color=green]
>> we know, a kernel task could be preemptived in 2.6, but i'm not sure
>> that does a ISR routine could be preemptived in 2.6.
>>
>> any one have practice with this problem? thanks for hare the
>> description on it.[/color]
>
> I'm no expert on kernel internals, but my guess (without checking) would be
> the ISR would need to be atomic.
>
> Otherwise, if an interrupt could interrupt the interrupt service routine
> causing the interrupt service routine to run again...
> Well, everything would get very messy very quickly.
> It might end up spending all its time attempting to service interrupts but
> not actually get a chance to complete any of them.[/color]
I'm looking at Robert Love's book on Linux Kernel Development, and it
says that interrupt handlers in Linux don't need to be reentrant,
because the corresponding interrupt line is masked out on all
processors on the system, so that the interrupt handler call is
never nested.
It also indicates that interrupt handlers are interruptable. They also
cannot block. They're divided into two halves, each half meant for
different work.
There's a lot to 'em, and I'd recommending finding that book (or its
equivalent on the web) and studying it. There's no pat answer.
--
No one can make you feel inferior without your consent.
-- Eleanor Roosevelt
On 2008-10-03, Chris Ahlstrom <linonut@bollsouth.nut> wrote:[color=blue]
> After takin' a swig o' grog, Andrew Halliwell belched out
> this bit o' wisdom:
>[color=green]
>> lion3875 <lion3875@gmail.com> wrote:[color=darkred]
>>> we know, a kernel task could be preemptived in 2.6, but i'm not sure
>>> that does a ISR routine could be preemptived in 2.6.
>>>
>>> any one have practice with this problem? thanks for hare the
>>> description on it.[/color]
>>
>> I'm no expert on kernel internals, but my guess (without checking) would be
>> the ISR would need to be atomic.
>>
>> Otherwise, if an interrupt could interrupt the interrupt service routine
>> causing the interrupt service routine to run again...
>> Well, everything would get very messy very quickly.
>> It might end up spending all its time attempting to service interrupts but
>> not actually get a chance to complete any of them.[/color]
>
> I'm looking at Robert Love's book on Linux Kernel Development, and it
> says that interrupt handlers in Linux don't need to be reentrant,
> because the corresponding interrupt line is masked out on all
> processors on the system, so that the interrupt handler call is
> never nested.
>
> It also indicates that interrupt handlers are interruptable. They also
> cannot block. They're divided into two halves, each half meant for
> different work.
>
> There's a lot to 'em, and I'd recommending finding that book (or its
> equivalent on the web) and studying it. There's no pat answer.[/color]
I thought you had to use the "CLI" instruction (x86) to disable
interrupts at the start of your interrupt handler then enable interrupts
with the "STI" instruction when your handler is finished. Data storage
has to be set using "sig_atomic_t" so that the data is read/written in
one instruction..
--
Regards,
Gregory.
Gentoo Linux - Penguin Power
After takin' a swig o' grog, Gregory Shearman belched out
this bit o' wisdom:
[color=blue]
> On 2008-10-03, Chris Ahlstrom <linonut@bollsouth.nut> wrote:
>[color=green]
>> There's a lot to 'em, and I'd recommending finding that book (or its
>> equivalent on the web) and studying it. There's no pat answer.[/color]
>
> I thought you had to use the "CLI" instruction (x86) to disable
> interrupts at the start of your interrupt handler then enable interrupts
> with the "STI" instruction when your handler is finished. Data storage
> has to be set using "sig_atomic_t" so that the data is read/written in
> one instruction..[/color]
Could be, but the Love's book didn't mention it. Maybe you don't have
to do that any more with the 2.6 kernel. Plus the top half requires a
different strategy from the bottom half, from what I've read.
--
Providence, New Jersey, is one of the few cities where Velveeta cheese
appears on the gourmet shelf.
On 2008-10-04, Chris Ahlstrom <linonut@bollsouth.nut> wrote:[color=blue]
> After takin' a swig o' grog, Gregory Shearman belched out
> this bit o' wisdom:
>[color=green]
>> On 2008-10-03, Chris Ahlstrom <linonut@bollsouth.nut> wrote:
>>[color=darkred]
>>> There's a lot to 'em, and I'd recommending finding that book (or its
>>> equivalent on the web) and studying it. There's no pat answer.[/color]
>>
>> I thought you had to use the "CLI" instruction (x86) to disable
>> interrupts at the start of your interrupt handler then enable interrupts
>> with the "STI" instruction when your handler is finished. Data storage
>> has to be set using "sig_atomic_t" so that the data is read/written in
>> one instruction..[/color]
>
> Could be, but the Love's book didn't mention it. Maybe you don't have
> to do that any more with the 2.6 kernel. Plus the top half requires a
> different strategy from the bottom half, from what I've read.[/color]
Hmmm... perhaps C either implicitly sets these instructions or doesn't
worry about reentrancy and leaves it up to the programmer to handle
these probs, ie setting up a signal queue...
Can't really remember that much. I used to do a lot of signal handling
once upon a time, but not much these days.
--
Regards,
Gregory.
Gentoo Linux - Penguin Power
On Oct 3, 7:39*am, Andrew Halliwell <spi...@ponder.sky.com> wrote:[color=blue]
> lion3875 <lion3...@gmail.com> wrote:[color=green]
> > we know, a kernel task could be preemptived in 2.6, but i'm not sure
> > that does a ISR routine could be preemptived in 2.6.[/color]
>[color=green]
> > any one have practice with this problem? thanks for hare the
> > description on it.[/color]
>
> I'm no expert on kernel internals, but my guess (without checking) would be
> the ISR would need to be atomic.
>
> Otherwise, if an interrupt could interrupt the interrupt service routine
> causing the interrupt service routine to run again...
> Well, everything would get very messy very quickly.
> It might end up spending all its time attempting to service interrupts but
> not actually get a chance to complete any of them.[/color]
You mask the interrupt(s) you want to ignore.
As for the original question, certain ISRs are already preempted by
other ISRs. What problem are trying to fix?
After takin' a swig o' grog, Gregory Shearman belched out
this bit o' wisdom:
[color=blue]
> On 2008-10-04, Chris Ahlstrom <linonut@bollsouth.nut> wrote:[color=green]
>>
>> Could be, but the Love's book didn't mention it. Maybe you don't have
>> to do that any more with the 2.6 kernel. Plus the top half requires a
>> different strategy from the bottom half, from what I've read.[/color]
>
> Hmmm... perhaps C either implicitly sets these instructions or doesn't
> worry about reentrancy and leaves it up to the programmer to handle
> these probs, ie setting up a signal queue...
>
> Can't really remember that much. I used to do a lot of signal handling
> once upon a time, but not much these days.[/color]
And I've never done it at all, just some light reading on it.
--
Monitor not included.
Chris Ahlstrom <linonut@bollsouth.nut> writes:
[color=blue]
> After takin' a swig o' grog, Gregory Shearman belched out
> this bit o' wisdom:
>[color=green]
>> On 2008-10-04, Chris Ahlstrom <linonut@bollsouth.nut> wrote:[color=darkred]
>>>
>>> Could be, but the Love's book didn't mention it. Maybe you don't have
>>> to do that any more with the 2.6 kernel. Plus the top half requires a
>>> different strategy from the bottom half, from what I've read.[/color]
>>
>> Hmmm... perhaps C either implicitly sets these instructions or doesn't
>> worry about reentrancy and leaves it up to the programmer to handle
>> these probs, ie setting up a signal queue...
>>
>> Can't really remember that much. I used to do a lot of signal handling
>> once upon a time, but not much these days.[/color]
>
> And I've never done it at all, just some light reading on it.[/color]
Thanks for that contribution.
C doesn't "implicitly" do anything. Its not defined in the standard.
All handling must be done at the programmer level. In some cases kernel
type code drops into ASM for platform specific non divisible operators
to achieve this level of lock.
On 3 Oct 2008 23:58:11 GMT, Gregory Shearman <ZekeGregory@netscape.net> wrote:
[color=blue]
> I thought you had to use the "CLI" instruction (x86) to disable
> interrupts at the start of your interrupt handler then enable
> interrupts with the "STI" instruction when your handler is finished.[/color]
That was never the right procedure, even in DOS. For one thing, it
disables all interrupts on the current CPU, which is almost never
necessary (see below).
For another, the sti will always hard enable interrupts even if they
were already disabled by the OS before your handler was called. That
may not be a good idea. For that reason you should at least use the
save/restore flags macros instead of cli/sti.
In addition, the traditional x86 interrupt controller hardware masks the
particular irq for your handler before the handler is called. So you
can only be interrupted by higher-priority irq's, not another one of the
same kind or lower.
Linux carries this behavior across architectures.
--
-| Comrade Bob Hauck
-| Proud part owner of the People's Insurance Company (formerly AIG)
-| [url]http://www.haucks.org/[/url]
On Fri, 3 Oct 2008 12:39:28 +0100, Andrew Halliwell
<spike1@ponder.sky.com> wrote:
[color=blue]
> I'm no expert on kernel internals, but my guess (without checking)
> would be the ISR would need to be atomic.[/color]
Most interrupt controllers disable further interrupts at the same or
lower priority levels until the current one is cleared. The ISR or the
OS is responsible for this, depending on the system design.
[color=blue]
> Otherwise, if an interrupt could interrupt the interrupt service
> routine causing the interrupt service routine to run again...[/color]
ISR's typically allow higher-priority interrupts to happen while they
run. This is usually not a problem. If it is, then the ISR must
disable interrupts globally until it is safe to enable them again.
[color=blue]
> It might end up spending all its time attempting to service interrupts
> but not actually get a chance to complete any of them.[/color]
That can happen anyway if interrupts arrive at a high enough rate. Or
if they are level-triggered and the ISR fails to clear them in the
hardware that's requesting service 8->
--
-| Comrade Bob Hauck
-| Proud part owner of the People's Insurance Company (formerly AIG)
-| [url]http://www.haucks.org/[/url]