Is it possible to disable system wide interrupts under windows(all) ?
Thx,
Hassan
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You can always disable interrupts on your current cpu, but I’m not sure that
is what you were asking. Try KeRaiseIrql to HIGH_LEVEL. This will not
disable NMI interrupts. It also leaves the other processors happily
servicing interrupts. Finally it is generally not a good idea, but if you
have a reason it is a valid supported kernel api.
-----Original Message-----
From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
Sent: Tuesday, September 18, 2001 9:00 PM
To: NT Developers Interest List
Subject: [ntdev] disable interrupts
Is it possible to disable system wide interrupts under windows(all) ?
Thx,
Hassan
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Yes, but you have to answer the question “Do we REALLY need to do this?” You
can always clear the interrupt mask (CLI on an x86).
In almost ALL cases when we think we need this, we are dealing with a poor
design that needs to be re-thought anyway. I said ALMOST because there are
times when it is the only way. When you do that, remember you will then lock
your code into the x86 processor.
Gary G. Little
Staff Engineer
Broadband Storage, Inc.
xxxxx@broadstor.com
-----Original Message-----
From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
Sent: Tuesday, September 18, 2001 6:00 PM
To: NT Developers Interest List
Subject: [ntdev] disable interrupts
Is it possible to disable system wide interrupts under windows(all) ?
Thx,
Hassan
You are currently subscribed to ntdev as: xxxxx@broadstor.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
I agree with what you are saying. We are developing drivers for both Linux
and Windows and wants to share as much code as possible and provide a
consistent api to applications above.
I was told the only way to execute a critical section in Linux Kernel
(without doing too much) is to disable all interrupts. For the time being
our interrupt api needs to behave consistently on both platforms and hence
the need to for disabling interrupts on windows.
The design clearly needs more thought : ) Thanks anyways.
Hassan
From: Gary Little
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] RE: disable interrupts
>Date: Wed, 19 Sep 2001 11:52:20 -0700
>
>Yes, but you have to answer the question “Do we REALLY need to do this?”
>You
>can always clear the interrupt mask (CLI on an x86).
>
>In almost ALL cases when we think we need this, we are dealing with a poor
>design that needs to be re-thought anyway. I said ALMOST because there are
>times when it is the only way. When you do that, remember you will then
>lock
>your code into the x86 processor.
>
>Gary G. Little
>Staff Engineer
>Broadband Storage, Inc.
>xxxxx@broadstor.com
>
>-----Original Message-----
>From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
>Sent: Tuesday, September 18, 2001 6:00 PM
>To: NT Developers Interest List
>Subject: [ntdev] disable interrupts
>
>Is it possible to disable system wide interrupts under windows(all) ?
>
>Thx,
>Hassan
>
>—
>You are currently subscribed to ntdev as: xxxxx@broadstor.com
>To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>—
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You need to abstract the interface from the implementation. So for both
platforms you need a critical section start, critical section stop pair
of operators. You define such a thing. You use whatever Linux supports
(cli/sti) as the Linux implementation and you use one of NT’s
serialization mechanisms for the NT implementation. Your portable code
remains portable. It would be a way bad idea to force NT to do things
the Linux way, and visa versa.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Hassan I Khan
Sent: Thursday, September 20, 2001 12:42 AM
To: NT Developers Interest List
Subject: [ntdev] RE: disable interruptsI agree with what you are saying. We are developing drivers
for both Linux
and Windows and wants to share as much code as possible and provide a
consistent api to applications above.I was told the only way to execute a critical section in Linux Kernel
(without doing too much) is to disable all interrupts. For
the time being
our interrupt api needs to behave consistently on both
platforms and hence
the need to for disabling interrupts on windows.The design clearly needs more thought : ) Thanks anyways.
Hassan
>From: Gary Little
> >Reply-To: “NT Developers Interest List”
> >To: “NT Developers Interest List”
> >Subject: [ntdev] RE: disable interrupts
> >Date: Wed, 19 Sep 2001 11:52:20 -0700
> >
> >Yes, but you have to answer the question “Do we REALLY need to do
> >this?”
> >You
> >can always clear the interrupt mask (CLI on an x86).
> >
> >In almost ALL cases when we think we need this, we are
> dealing with a
> >poor design that needs to be re-thought anyway. I said
> ALMOST because
> >there are times when it is the only way. When you do that,
> remember you
> >will then lock your code into the x86 processor.
> >
> >Gary G. Little
> >Staff Engineer
> >Broadband Storage, Inc.
> >xxxxx@broadstor.com
> >
> >-----Original Message-----
> >From: xxxxx@hotmail.com
> [mailto:xxxxx@hotmail.com]
> >Sent: Tuesday,
> September 18, 2001 6:00 PM
> >To: NT Developers Interest List
> >Subject: [ntdev] disable interrupts
> >
> >Is it possible to disable system wide interrupts under windows(all) ?
> >
> >Thx,
> >Hassan
> >
> >—
> >You are currently subscribed to ntdev as: xxxxx@broadstor.com To
> >unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
> >—
> >You are currently subscribed to ntdev as:
> xxxxx@hotmail.com
> >To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at
> http://explorer.msn.com/intl.asp
>
>
> —
> You are currently
> subscribed to ntdev as: xxxxx@hollistech.com To unsubscribe
> send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Correct me if I am wrong, but CLI/STI only work on the current processor,
yes?
If you truly needed to shutdown interrupts on the whole system, I would
queue a DPC to each processor using KeSetTargetProcessorDpc perhaps. Have
each of those DPCs race to set an interlocked variable, and raise their
IRQL. Whoever was able to set the interlocked variable, would be the
winner, and would be the Dpc that actually did some work. The other DPCs
could loop waiting for the interlocked variable to get reset, then quit
when it was. Something along these lines anyway. This is all theoretical,
as I haven’t tried it, but it seems it should be possible. It will not
stop all interrupts, such as NMIs as was noted by Mark, but it would
probably suffice for most uses. I would never use this approach if I could
at all possibly help it, but this is as close as I can imagine getting to
truly turning off interrupts. Whatever work was done, had better be done
quickly, as I doubt the system integrity would hold up for long with
interrupts being held off in this manner. But, this would be platform
independent. I will have to test this out now 
Bill M.
On 09/19/01, “Gary Little ” wrote:
> Yes, but you have to answer the question “Do we REALLY need to do this?” You
> can always clear the interrupt mask (CLI on an x86).
>
> In almost ALL cases when we think we need this, we are dealing with a poor
> design that needs to be re-thought anyway. I said ALMOST because there are
> times when it is the only way. When you do that, remember you will then lock
> your code into the x86 processor.
>
> Gary G. Little
> Staff Engineer
> Broadband Storage, Inc.
> xxxxx@broadstor.com
>
> -----Original Message-----
> From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
> Sent: Tuesday, September 18, 2001 6:00 PM
> To: NT Developers Interest List
> Subject: [ntdev] disable interrupts
>
> Is it possible to disable system wide interrupts under windows(all) ?
>
> Thx,
> Hassan
>
> —
> You are currently subscribed to ntdev as: xxxxx@broadstor.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Actually he was proposing the solution without stating the problem. He
needed a critical section barrier (a mutex of some sort.) But you are
correct, CLI/STI affect the current cpu only. This is hardly ever the right
solution to anything, and is certainly the wrong solution to serialization
on NT. I’m guessing it isn’t the right way for MP Linux either, but I
wouldn’t know.
Your queue targeted dpcs algorithm works fine as long as you raise your
interrupt level before you spin rather than after
-----Original Message-----
From: xxxxx@bsquare.com [mailto:xxxxx@bsquare.com]
Sent: Wednesday, September 19, 2001 8:45 PM
To: NT Developers Interest List
Subject: [ntdev] RE: disable interrupts
Correct me if I am wrong, but CLI/STI only work on the current processor,
yes?
If you truly needed to shutdown interrupts on the whole system, I would
queue a DPC to each processor using KeSetTargetProcessorDpc perhaps. Have
each of those DPCs race to set an interlocked variable, and raise their
IRQL. Whoever was able to set the interlocked variable, would be the
winner, and would be the Dpc that actually did some work. The other DPCs
could loop waiting for the interlocked variable to get reset, then quit
when it was. Something along these lines anyway. This is all theoretical,
as I haven’t tried it, but it seems it should be possible. It will not
stop all interrupts, such as NMIs as was noted by Mark, but it would
probably suffice for most uses. I would never use this approach if I could
at all possibly help it, but this is as close as I can imagine getting to
truly turning off interrupts. Whatever work was done, had better be done
quickly, as I doubt the system integrity would hold up for long with
interrupts being held off in this manner. But, this would be platform
independent. I will have to test this out now
Bill M.
On 09/19/01, “Gary Little ” wrote:
> Yes, but you have to answer the question “Do we REALLY need to do
> this?” You can always clear the interrupt mask (CLI on an x86).
>
> In almost ALL cases when we think we need this, we are dealing with a
> poor design that needs to be re-thought anyway. I said ALMOST because
> there are times when it is the only way. When you do that, remember
> you will then lock your code into the x86 processor.
>
> Gary G. Little
> Staff Engineer
> Broadband Storage, Inc.
> xxxxx@broadstor.com
>
> -----Original Message-----
> From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
> Sent: Tuesday, September 18, 2001 6:00 PM
> To: NT Developers Interest List
> Subject: [ntdev] disable interrupts
>
> Is it possible to disable system wide interrupts under windows(all) ?
>
> Thx,
> Hassan
>
> —
> You are currently subscribed to ntdev as: xxxxx@broadstor.com To
> unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntdev as: xxxxx@stratus.com To
> unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
The easiest way to make sure one’s not interrupted is to frig the IDT(s)
with pointers to interrupt routines that don’t do anything but an IRET. Even
simpler, have your own IDT pre-built, and set it up with a load IDT
instruction. You can selectively enable and disable interrupts at will by
overwriting your own IDT’s entries, then, when you finish, just flip back to
Windows’s own IDT. You get the added bonus that while you’re running on your
own IDT, you can control how much i/o you’ll let Windows know about. That’ll
take care of NMIs and multiple processors, and avoid a lot of aggravation
generated by cli/sti pairs.
Alberto.
-----Original Message-----
From: xxxxx@bsquare.com [mailto:xxxxx@bsquare.com]
Sent: Wednesday, September 19, 2001 8:45 PM
To: NT Developers Interest List
Subject: [ntdev] RE: disable interrupts
Correct me if I am wrong, but CLI/STI only work on the current processor,
yes?
If you truly needed to shutdown interrupts on the whole system, I would
queue a DPC to each processor using KeSetTargetProcessorDpc perhaps. Have
each of those DPCs race to set an interlocked variable, and raise their
IRQL. Whoever was able to set the interlocked variable, would be the
winner, and would be the Dpc that actually did some work. The other DPCs
could loop waiting for the interlocked variable to get reset, then quit
when it was. Something along these lines anyway. This is all theoretical,
as I haven’t tried it, but it seems it should be possible. It will not
stop all interrupts, such as NMIs as was noted by Mark, but it would
probably suffice for most uses. I would never use this approach if I could
at all possibly help it, but this is as close as I can imagine getting to
truly turning off interrupts. Whatever work was done, had better be done
quickly, as I doubt the system integrity would hold up for long with
interrupts being held off in this manner. But, this would be platform
independent. I will have to test this out now
Bill M.
On 09/19/01, “Gary Little ” wrote:
> Yes, but you have to answer the question “Do we REALLY need to do this?”
You
> can always clear the interrupt mask (CLI on an x86).
>
> In almost ALL cases when we think we need this, we are dealing with a poor
> design that needs to be re-thought anyway. I said ALMOST because there are
> times when it is the only way. When you do that, remember you will then
lock
> your code into the x86 processor.
>
> Gary G. Little
> Staff Engineer
> Broadband Storage, Inc.
> xxxxx@broadstor.com
>
> -----Original Message-----
> From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
> Sent: Tuesday, September 18, 2001 6:00 PM
> To: NT Developers Interest List
> Subject: [ntdev] disable interrupts
>
> Is it possible to disable system wide interrupts under windows(all) ?
>
> Thx,
> Hassan
>
> —
> You are currently subscribed to ntdev as: xxxxx@broadstor.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntdev as: xxxxx@compuware.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are kidding, right?
-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Thursday, September 20, 2001 11:04 AM
To: NT Developers Interest List
Subject: [ntdev] RE: disable interrupts
The easiest way to make sure one’s not interrupted is to frig the IDT(s)
with pointers to interrupt routines that don’t do anything but an IRET. Even
simpler, have your own IDT pre-built, and set it up with a load IDT
instruction. You can selectively enable and disable interrupts at will by
overwriting your own IDT’s entries, then, when you finish, just flip back to
Windows’s own IDT. You get the added bonus that while you’re running on your
own IDT, you can control how much i/o you’ll let Windows know about. That’ll
take care of NMIs and multiple processors, and avoid a lot of aggravation
generated by cli/sti pairs.
Alberto.
-----Original Message-----
From: xxxxx@bsquare.com [mailto:xxxxx@bsquare.com]
Sent: Wednesday, September 19, 2001 8:45 PM
To: NT Developers Interest List
Subject: [ntdev] RE: disable interrupts
Correct me if I am wrong, but CLI/STI only work on the current processor,
yes?
If you truly needed to shutdown interrupts on the whole system, I would
queue a DPC to each processor using KeSetTargetProcessorDpc perhaps. Have
each of those DPCs race to set an interlocked variable, and raise their
IRQL. Whoever was able to set the interlocked variable, would be the
winner, and would be the Dpc that actually did some work. The other DPCs
could loop waiting for the interlocked variable to get reset, then quit
when it was. Something along these lines anyway. This is all theoretical,
as I haven’t tried it, but it seems it should be possible. It will not
stop all interrupts, such as NMIs as was noted by Mark, but it would
probably suffice for most uses. I would never use this approach if I could
at all possibly help it, but this is as close as I can imagine getting to
truly turning off interrupts. Whatever work was done, had better be done
quickly, as I doubt the system integrity would hold up for long with
interrupts being held off in this manner. But, this would be platform
independent. I will have to test this out now
Bill M.
On 09/19/01, “Gary Little ” wrote:
> Yes, but you have to answer the question “Do we REALLY need to do
> this?”
You
> can always clear the interrupt mask (CLI on an x86).
>
> In almost ALL cases when we think we need this, we are dealing with a
> poor design that needs to be re-thought anyway. I said ALMOST because
> there are times when it is the only way. When you do that, remember
> you will then
lock
> your code into the x86 processor.
>
> Gary G. Little
> Staff Engineer
> Broadband Storage, Inc.
> xxxxx@broadstor.com
>
> -----Original Message-----
> From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
> Sent: Tuesday, September 18, 2001 6:00 PM
> To: NT Developers Interest List
> Subject: [ntdev] disable interrupts
>
> Is it possible to disable system wide interrupts under windows(all) ?
>
> Thx,
> Hassan
>
> —
> You are currently subscribed to ntdev as: xxxxx@broadstor.com To
> unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@compuware.com To unsubscribe send a blank email to
> leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@compuware.com To
unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Nope, I’m dead serious. It may be the way I am, but I like to be in control
of what I’m trying to control. If you can afford to lose the interrupt, an
IRET will do the job. If not, depending on the hardware, you can table the
interrupt, that is, queue it up for further action. One LIDT per processor,
and I have full control of the I/O system ! And the OS will only see what
and when I decide to let through.
It’s easier than it looks. Just copy the whole IDT into your own memory,
frig it, and change the IDTR. Hey, maybe we should add a “mockIDT” class to
our DriverWorks! It’s only 256 entries anyway, what’s the big deal ?
Alberto.
-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Thursday, September 20, 2001 11:24 AM
To: NT Developers Interest List
Subject: [ntdev] RE: disable interrupts
You are kidding, right?
-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Thursday, September 20, 2001 11:04 AM
To: NT Developers Interest List
Subject: [ntdev] RE: disable interrupts
The easiest way to make sure one’s not interrupted is to frig the IDT(s)
with pointers to interrupt routines that don’t do anything but an IRET. Even
simpler, have your own IDT pre-built, and set it up with a load IDT
instruction. You can selectively enable and disable interrupts at will by
overwriting your own IDT’s entries, then, when you finish, just flip back to
Windows’s own IDT. You get the added bonus that while you’re running on your
own IDT, you can control how much i/o you’ll let Windows know about. That’ll
take care of NMIs and multiple processors, and avoid a lot of aggravation
generated by cli/sti pairs.
Alberto.
-----Original Message-----
From: xxxxx@bsquare.com [mailto:xxxxx@bsquare.com]
Sent: Wednesday, September 19, 2001 8:45 PM
To: NT Developers Interest List
Subject: [ntdev] RE: disable interrupts
Correct me if I am wrong, but CLI/STI only work on the current processor,
yes?
If you truly needed to shutdown interrupts on the whole system, I would
queue a DPC to each processor using KeSetTargetProcessorDpc perhaps. Have
each of those DPCs race to set an interlocked variable, and raise their
IRQL. Whoever was able to set the interlocked variable, would be the
winner, and would be the Dpc that actually did some work. The other DPCs
could loop waiting for the interlocked variable to get reset, then quit
when it was. Something along these lines anyway. This is all theoretical,
as I haven’t tried it, but it seems it should be possible. It will not
stop all interrupts, such as NMIs as was noted by Mark, but it would
probably suffice for most uses. I would never use this approach if I could
at all possibly help it, but this is as close as I can imagine getting to
truly turning off interrupts. Whatever work was done, had better be done
quickly, as I doubt the system integrity would hold up for long with
interrupts being held off in this manner. But, this would be platform
independent. I will have to test this out now
Bill M.
On 09/19/01, “Gary Little ” wrote:
> Yes, but you have to answer the question “Do we REALLY need to do
> this?”
You
> can always clear the interrupt mask (CLI on an x86).
>
> In almost ALL cases when we think we need this, we are dealing with a
> poor design that needs to be re-thought anyway. I said ALMOST because
> there are times when it is the only way. When you do that, remember
> you will then
lock
> your code into the x86 processor.
>
> Gary G. Little
> Staff Engineer
> Broadband Storage, Inc.
> xxxxx@broadstor.com
>
> -----Original Message-----
> From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
> Sent: Tuesday, September 18, 2001 6:00 PM
> To: NT Developers Interest List
> Subject: [ntdev] disable interrupts
>
> Is it possible to disable system wide interrupts under windows(all) ?
>
> Thx,
> Hassan
>
> —
> You are currently subscribed to ntdev as: xxxxx@broadstor.com To
> unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@compuware.com To unsubscribe send a blank email to
> leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@compuware.com To
unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
And people wonder why NT is so unstable compared to other OSes (namely VMS).
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Moreira, Alberto
Sent: Thursday, September 20, 2001 10:42 AM
To: NT Developers Interest List
Subject: [ntdev] RE: disable interrupts
Nope, I’m dead serious. It may be the way I am, but I like to be in control
of what I’m trying to control. If you can afford to lose the interrupt, an
IRET will do the job. If not, depending on the hardware, you can table the
interrupt, that is, queue it up for further action. One LIDT per processor,
and I have full control of the I/O system ! And the OS will only see what
and when I decide to let through.
It’s easier than it looks. Just copy the whole IDT into your own memory,
frig it, and change the IDTR. Hey, maybe we should add a “mockIDT” class to
our DriverWorks! It’s only 256 entries anyway, what’s the big deal ?
Alberto.
-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Thursday, September 20, 2001 11:24 AM
To: NT Developers Interest List
Subject: [ntdev] RE: disable interrupts
You are kidding, right?
-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Thursday, September 20, 2001 11:04 AM
To: NT Developers Interest List
Subject: [ntdev] RE: disable interrupts
The easiest way to make sure one’s not interrupted is to frig the IDT(s)
with pointers to interrupt routines that don’t do anything but an IRET. Even
simpler, have your own IDT pre-built, and set it up with a load IDT
instruction. You can selectively enable and disable interrupts at will by
overwriting your own IDT’s entries, then, when you finish, just flip back to
Windows’s own IDT. You get the added bonus that while you’re running on your
own IDT, you can control how much i/o you’ll let Windows know about. That’ll
take care of NMIs and multiple processors, and avoid a lot of aggravation
generated by cli/sti pairs.
Alberto.
-----Original Message-----
From: xxxxx@bsquare.com [mailto:xxxxx@bsquare.com]
Sent: Wednesday, September 19, 2001 8:45 PM
To: NT Developers Interest List
Subject: [ntdev] RE: disable interrupts
Correct me if I am wrong, but CLI/STI only work on the current processor,
yes?
If you truly needed to shutdown interrupts on the whole system, I would
queue a DPC to each processor using KeSetTargetProcessorDpc perhaps. Have
each of those DPCs race to set an interlocked variable, and raise their
IRQL. Whoever was able to set the interlocked variable, would be the
winner, and would be the Dpc that actually did some work. The other DPCs
could loop waiting for the interlocked variable to get reset, then quit
when it was. Something along these lines anyway. This is all theoretical,
as I haven’t tried it, but it seems it should be possible. It will not
stop all interrupts, such as NMIs as was noted by Mark, but it would
probably suffice for most uses. I would never use this approach if I could
at all possibly help it, but this is as close as I can imagine getting to
truly turning off interrupts. Whatever work was done, had better be done
quickly, as I doubt the system integrity would hold up for long with
interrupts being held off in this manner. But, this would be platform
independent. I will have to test this out now
Bill M.
On 09/19/01, “Gary Little ” wrote:
> Yes, but you have to answer the question “Do we REALLY need to do
> this?”
You
> can always clear the interrupt mask (CLI on an x86).
>
> In almost ALL cases when we think we need this, we are dealing with a
> poor design that needs to be re-thought anyway. I said ALMOST because
> there are times when it is the only way. When you do that, remember
> you will then
lock
> your code into the x86 processor.
>
> Gary G. Little
> Staff Engineer
> Broadband Storage, Inc.
> xxxxx@broadstor.com
>
> -----Original Message-----
> From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
> Sent: Tuesday, September 18, 2001 6:00 PM
> To: NT Developers Interest List
> Subject: [ntdev] disable interrupts
>
> Is it possible to disable system wide interrupts under windows(all) ?
>
> Thx,
> Hassan
>
> —
> You are currently subscribed to ntdev as: xxxxx@broadstor.com To
> unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@compuware.com To unsubscribe send a blank email to
> leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@compuware.com To
unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@pdq.net
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
“Moreira, Alberto” wrote in message
news:xxxxx@ntdev…
> It’s easier than it looks. Just copy the whole IDT into your own memory,
> frig it, and change the IDTR. Hey, maybe we should add a “mockIDT” class
to
> our DriverWorks! It’s only 256 entries anyway, what’s the big deal ?
>
If your note was intended as flame bait, I’ll swallow.
That is simply THE most hideous, irresponsible, architecturally abberant,
hack I have ever heard in my 20+ years of driver writing.
You really have no idea of what side-effects this may cause in the O/S,
Alberto. Or what problems doing this might cause for other drivers. Not to
mention, if I frig the IDT in MY driver, and you frig it in YOURS, then
what’s the result?? Duh!? This isn’t DOS. It isn’t Windows 3.1 – It’s a
real, general purpose, operating system.
Because I’m in a particularly good mood, I might grant that such techniques
might be applicable in a very specific environment (embedded tool, etc).
To suggest, however, that this is a reasonable, generically applicable,
solution to a common question such as the one posted is not engineering. And
it certainly does no service to the community of developers who are trying
to learn to write Windows drivers. One does not use a sledge hammer when a
screwdriver can accomplish what’s required.
I s’pose if all you HAVE is a sledge hammer, then everything looks like a
pile of rock though…
Peter
OSR
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com