RE: Re[2]: disable interrupts

OSR_Community_User · September 20, 2001, 3:59pm

OIC, so suddenly this approach of yours is not quite so simple, is it? Would
you like another shovel, or is one enough?

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Thursday, September 20, 2001 2:16 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Re[2]: disable interrupts

Of course you have to know your hardware. But that’s between your code and
the iron, and it’s your decision whether or not you’re going to tell the OS
what’s going on.

Alberto.

-----Original Message-----
From: Norbert Kawulski [mailto:xxxxx@stollmann.de]
Sent: Thursday, September 20, 2001 12:31 PM
To: NT Developers Interest List
Subject: [ntdev] Re[2]: disable interrupts

How is a level-triggered interrupt acknowlegded with an IRET ? AFAIK the cpu
blocks at that irql (and lower ones).

“You are never alone with a schizophrenic.”

“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: xxxxx@stollmann.de
> 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

OSR_Community_User · September 20, 2001, 4:06pm

I’m just saying, people use those techniques and the stuff they write works.
Hence, the “stability” thing is a nonissue. The distinction between
“diagnostic” tools and “garden-variety” drivers is yours - I don’t see the
need for that distinction!

Alberto.

-----Original Message-----
From: Peter Viscarola [mailto:xxxxx@osr.com]
Sent: Thursday, September 20, 2001 2:41 PM
To: NT Developers Interest List
Subject: [ntdev] Re: disable interrupts

“Moreira, Alberto” wrote in message
news:xxxxx@ntdev…
>
> OS. If doing this kind of thing was hideous, irresponsible,
> architecturally aberrant, neither SoftIce nor BoundsChecker would work,
> would they ?
>

Being hideous, irresponsible, and architecturally aberrant (one “b” or two?)
has little to do with whether something WORKS. On its own. For a while.

As we’ve discussed before, to what is I’m sure the considerable boredom of
other list members, these are DIAGNOSTIC TOOLS. A whole separate category.
Such things often must be architecturally aberrant by definition, if they
are to achieve their design goals. Not so for garden-variety drivers.

In any case, I don’t think it would help either of us to be drawn into a
discussion of my opinion of these tools or their design. I don’t think this
is a proper venue for such a discussion.

>
> Or VMWare, for that matter ?
>
We are not talking about writing VMWare here. VMWare runs UNDER the
operating system, not ON it.

>
>There’s more to kernel level
> programming than writing drivers that adhere to the party line !
>

I am not one to advocate the “party line”, dude. Or perhaps you don’t read
The NT Insider… ANYhow, what I’m advocating for here is merely good
engineering practice.

>
> To me, the OS is just a component - it is NOT the guy in charge, nor is it
a
> cop.
>

That is no way to write drivers that will “work and play well with others”
which is a primary requirement. By agreeing on a set of basic design tenets,
we create a predictable environment in which components developed by widely
disparate groups have a reasonable likelihood of working together. If
everyone just “does there own thing” there’s no way for anybody to predict
the environment in which their software will be running.

I wholeheartedly agree that what you’re advocating is appropriate when you
can predict the environment: A closed system where YOU control the
components.

In a general purpose system “I’ll just do whatever I want, and frig everyone
else” stops working very quickly… in fact, it stops working immediately
when two people try to play that game simultaneously.

I’m out of this discussion now. You’re welcome to the last word if you want
it,

Peter
OSR

—
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

Gregory_G_Dyess · September 20, 2001, 4:15pm

You shouldn’t be doing Windows programming with that attitude. If you are
doing special-purpose one-of-a-kind hardware development for reconfigured,
non-changeable systems that are not being sold to the general public, then
your attitude is acceptable, barely. The OS IS the guy in charge, not you
or your component. If every developer had your attitude, Windows would be
even more unstable than it already is. I would highly recommend that no one
buy any products from you company, ever!

Greg

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Moreira, Alberto
Sent: Thursday, September 20, 2001 1:13 PM
To: NT Developers Interest List
Subject: [ntdev] Re: disable interrupts

Peter…

I’m not in the troll business. But you’re talking to someone who programs at
hardware level, who’s in the business of running independent and sometimes
in spite of the OS. If doing this kind of thing was hideous, irresponsible,
architecturally aberrant, neither SoftIce nor BoundsChecker would work,
would they ? Or VMWare, for that matter ? There’s more to kernel level
programming than writing drivers that adhere to the party line !

If I don’t want to be interrupted, I don’t want to be interrupted - and I’m
not going to let the OS tell me whether or not I’m entitled not to be
interrupted. If I decide not to be interrupted, you can be sure the OS is
not going to interrupt me, and I’ll get the OS out of the way if need be.

To me, the OS is just a component - it is NOT the guy in charge, nor is it a
cop.

Alberto.

-----Original Message-----
From: Peter Viscarola [mailto:xxxxx@osr.com]
Sent: Thursday, September 20, 2001 12:18 PM
To: NT Developers Interest List
Subject: [ntdev] Re: disable interrupts

“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: 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

Gregory_G_Dyess · September 20, 2001, 4:18pm

Alberto,
What products does your company produce? I want to know so I can
black-list them immediately!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Moreira, Alberto
Sent: Thursday, September 20, 2001 3:03 PM
To: NT Developers Interest List
Subject: [ntdev] Re: disable interrupts

I’m just saying, people use those techniques and the stuff they write works.
Hence, the “stability” thing is a nonissue. The distinction between
“diagnostic” tools and “garden-variety” drivers is yours - I don’t see the
need for that distinction!

Alberto.

-----Original Message-----
From: Peter Viscarola [mailto:xxxxx@osr.com]
Sent: Thursday, September 20, 2001 2:41 PM
To: NT Developers Interest List
Subject: [ntdev] Re: disable interrupts

“Moreira, Alberto” wrote in message
news:xxxxx@ntdev…
>
> OS. If doing this kind of thing was hideous, irresponsible,
> architecturally aberrant, neither SoftIce nor BoundsChecker would work,
> would they ?
>

Being hideous, irresponsible, and architecturally aberrant (one “b” or two?)
has little to do with whether something WORKS. On its own. For a while.

As we’ve discussed before, to what is I’m sure the considerable boredom of
other list members, these are DIAGNOSTIC TOOLS. A whole separate category.
Such things often must be architecturally aberrant by definition, if they
are to achieve their design goals. Not so for garden-variety drivers.

In any case, I don’t think it would help either of us to be drawn into a
discussion of my opinion of these tools or their design. I don’t think this
is a proper venue for such a discussion.

>
> Or VMWare, for that matter ?
>
We are not talking about writing VMWare here. VMWare runs UNDER the
operating system, not ON it.

>
>There’s more to kernel level
> programming than writing drivers that adhere to the party line !
>

I am not one to advocate the “party line”, dude. Or perhaps you don’t read
The NT Insider… ANYhow, what I’m advocating for here is merely good
engineering practice.

>
> To me, the OS is just a component - it is NOT the guy in charge, nor is it
a
> cop.
>

That is no way to write drivers that will “work and play well with others”
which is a primary requirement. By agreeing on a set of basic design tenets,
we create a predictable environment in which components developed by widely
disparate groups have a reasonable likelihood of working together. If
everyone just “does there own thing” there’s no way for anybody to predict
the environment in which their software will be running.

I wholeheartedly agree that what you’re advocating is appropriate when you
can predict the environment: A closed system where YOU control the
components.

In a general purpose system “I’ll just do whatever I want, and frig everyone
else” stops working very quickly… in fact, it stops working immediately
when two people try to play that game simultaneously.

I’m out of this discussion now. You’re welcome to the last word if you want
it,

Peter
OSR

—
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

OSR_Community_User · September 20, 2001, 5:00pm

Your call. We do SoftICE, BoundsChecker, and others.

Alberto.

-----Original Message-----
From: Gregory G. Dyess [mailto:xxxxx@pdq.net]
Sent: Thursday, September 20, 2001 4:15 PM
To: NT Developers Interest List
Subject: [ntdev] Re: disable interrupts

Alberto,
What products does your company produce? I want to know so I can
black-list them immediately!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Moreira, Alberto
Sent: Thursday, September 20, 2001 3:03 PM
To: NT Developers Interest List
Subject: [ntdev] Re: disable interrupts

I’m just saying, people use those techniques and the stuff they write works.
Hence, the “stability” thing is a nonissue. The distinction between
“diagnostic” tools and “garden-variety” drivers is yours - I don’t see the
need for that distinction!

Alberto.

-----Original Message-----
From: Peter Viscarola [mailto:xxxxx@osr.com]
Sent: Thursday, September 20, 2001 2:41 PM
To: NT Developers Interest List
Subject: [ntdev] Re: disable interrupts

“Moreira, Alberto” wrote in message
news:xxxxx@ntdev…
>
> OS. If doing this kind of thing was hideous, irresponsible,
> architecturally aberrant, neither SoftIce nor BoundsChecker would work,
> would they ?
>

Being hideous, irresponsible, and architecturally aberrant (one “b” or two?)
has little to do with whether something WORKS. On its own. For a while.

As we’ve discussed before, to what is I’m sure the considerable boredom of
other list members, these are DIAGNOSTIC TOOLS. A whole separate category.
Such things often must be architecturally aberrant by definition, if they
are to achieve their design goals. Not so for garden-variety drivers.

In any case, I don’t think it would help either of us to be drawn into a
discussion of my opinion of these tools or their design. I don’t think this
is a proper venue for such a discussion.

>
> Or VMWare, for that matter ?
>
We are not talking about writing VMWare here. VMWare runs UNDER the
operating system, not ON it.

>
>There’s more to kernel level
> programming than writing drivers that adhere to the party line !
>

I am not one to advocate the “party line”, dude. Or perhaps you don’t read
The NT Insider… ANYhow, what I’m advocating for here is merely good
engineering practice.

>
> To me, the OS is just a component - it is NOT the guy in charge, nor is it
a
> cop.
>

That is no way to write drivers that will “work and play well with others”
which is a primary requirement. By agreeing on a set of basic design tenets,
we create a predictable environment in which components developed by widely
disparate groups have a reasonable likelihood of working together. If
everyone just “does there own thing” there’s no way for anybody to predict
the environment in which their software will be running.

I wholeheartedly agree that what you’re advocating is appropriate when you
can predict the environment: A closed system where YOU control the
components.

In a general purpose system “I’ll just do whatever I want, and frig everyone
else” stops working very quickly… in fact, it stops working immediately
when two people try to play that game simultaneously.

I’m out of this discussion now. You’re welcome to the last word if you want
it,

Peter
OSR

—
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: 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

OSR_Community_User · September 20, 2001, 6:31pm

>> … If every developer had your attitude, Windows would be

> even more unstable than it already is. I would highly recommend that no
one
> buy any products from you company, ever!

SoftICE is pretty good though

Alberto, are you working on the SoftICE project? (No offense, I’m just
curios)

Zoltan

Do You Yahoo!?

Get your free @yahoo.com address at http://mail.yahoo.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

OSR_Community_User · September 20, 2001, 7:31pm

>From: “Mark Roddy”
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] RE: disable interrupts
>Date: Wed, 19 Sep 2001 22:26:32 -0400
>
>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.
>

Sorry but I don’t know equivalent NT mechanism. Although I did read about
KeSynchroniseExecution (if thats what you re referring to ) but I would
really like to know what does Windows do to achieve this. I mean how does
windows prevent execution of an ISR on one processor while it is already
executing on the other. Inspite of spending close to a year on learning NT
device drivers I still am a novice. So please pardon these basic questions.

Hassan

_________________________________________________________________
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

OSR_Community_User · September 20, 2001, 8:01pm

Mark kick me in the shins if I’m wrong on this one …

Each IRQ is associated with an interrupt object, and within that interrupt
object is a spinlock. When a DIRQL event (interrupt or a sync call) occurs,
that spinlock is acquired. If it is already acquired then the cpu spins
until it is free, and it then acquires it, process the interrupt and
releases the spinlock. That spinlock is either created for you in
IoConnectInterrupt, or you create it, initialize it, and pass it to
IoConnectInterrupt.

Gary G. Little
Staff Engineer
Broadband Storage, Inc.
xxxxx@broadstor.com

-----Original Message-----
From: Hassan I Khan [mailto:xxxxx@hotmail.com]
Sent: Thursday, September 20, 2001 4:28 PM
To: NT Developers Interest List
Subject: [ntdev] RE: disable interrupts

From: “Mark Roddy”
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] RE: disable interrupts
>Date: Wed, 19 Sep 2001 22:26:32 -0400
>
>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.
>

Sorry but I don’t know equivalent NT mechanism. Although I did read about
KeSynchroniseExecution (if thats what you re referring to ) but I would
really like to know what does Windows do to achieve this. I mean how does
windows prevent execution of an ISR on one processor while it is already
executing on the other. Inspite of spending close to a year on learning NT
device drivers I still am a novice. So please pardon these basic questions.

Hassan

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

—
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

Mark_Roddy · September 20, 2001, 8:54pm

Gary has it about right. However, unless you are serializing direct
access to the hardware, including access by your ISR, the interrupt
object spinlock is not used for serialization, as it blocks other
hardware interrupts, (potentially on all CPUS,) and has been made
intentionally less than easy to use by the NT developers. Instead
executive spinlocks, events, mutex objects, resource locks etc. provide
a very rich set of tools for performing all sorts of serialization.

Without knowing the details of your project, it is pretty much
impossible to say what you need to use, other than to continue to
observe that CLI/STI or KeRaiseIrql are not the right approach. The
general way to decide which mechanism to use is to understand exactly
what interrupt levels all code paths that need to be serialized run at.
If the answer is PASSIVE_LEVEL (and more generally < DISPATCH_LEVEL)
then the high level abstract serialization mechanisms are appropriate:
resource locks, events, mutex and semaphore objects. If the answer is
that some code paths may execute at DISPATCH_LEVEL, but the hardware ISR
running at DIRQL is not involved, then the answer is an executive
spinlock acquired/released through KeAcquire/KeReleaseSpinlock. If the
answer is that you really do need to have serialization include your
ISR, then KeSynchronizeExecution is the mechanism. In the latter case
you may really have to look at this closely and separate the ISR cases
from all other serialization issues. Read the DDK. Buy one of the
several excellent books on NT kernel driver development.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary Little
Sent: Thursday, September 20, 2001 8:02 PM
To: NT Developers Interest List
Subject: [ntdev] RE: disable interrupts

Mark kick me in the shins if I’m wrong on this one …

Each IRQ is associated with an interrupt object, and within
that interrupt object is a spinlock. When a DIRQL event
(interrupt or a sync call) occurs, that spinlock is acquired.
If it is already acquired then the cpu spins until it is
free, and it then acquires it, process the interrupt and
releases the spinlock. That spinlock is either created for
you in IoConnectInterrupt, or you create it, initialize it,
and pass it to IoConnectInterrupt.

Gary G. Little
Staff Engineer
Broadband Storage, Inc.
xxxxx@broadstor.com

-----Original Message-----
From: Hassan I Khan [mailto:xxxxx@hotmail.com]
Sent: Thursday, September 20, 2001 4:28 PM
To: NT Developers Interest List
Subject: [ntdev] RE: disable interrupts

>From: “Mark Roddy”
> >Reply-To: “NT Developers Interest List”
> >To: “NT Developers Interest List”
> >Subject: [ntdev] RE: disable interrupts
> >Date: Wed, 19 Sep 2001 22:26:32 -0400
> >
> >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.
> >
>
> Sorry but I don’t know equivalent NT mechanism. Although I
> did read about KeSynchroniseExecution (if thats what you re
> referring to ) but I would really like to know what does
> Windows do to achieve this. I mean how does windows prevent
> execution of an ISR on one processor while it is already
> executing on the other. Inspite of spending close to a year
> on learning NT device drivers I still am a novice. So please
> pardon these basic questions.
>
> Hassan
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at
> http://explorer.msn.com/intl.asp
>
>
> —
> 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@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

OSR_Community_User · September 20, 2001, 8:58pm

At 11:03 AM 9/20/2001 -0400, you wrote:

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.

If I’m not mistaken, fiddling with the IDT will NOT absolutely guarantee no
interrupts. I believe you still could get system management mode
interrupts, which are not routed through the IDT, but through a hidden
register that is only accessible from SMM. My understanding is SMM is used
for things like power management, and memory fault analysis. The BIOS will
have a SMM handler that get’s invoked when certain events occur. This is
under ANY OS or kernel code that thinks it has control of the CPU, and
should be thought of as firmware that happens to use the normal CPU for
execution.

Jan

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

OSR_Community_User · September 20, 2001, 8:59pm

>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.

Thanks for reinforcing my belief that drivers should NOT run in an
unprotected environment. The assumption that kernel developers will “be
nice” just simply is not a valid assumption.

As a matter of fact, a bunch of media companies are attempting to make it
illegal to manufacturer computers that can be “frigged”. See
http://cryptome.org/sssca.htm

It seems like unprotected kernel mode software development is down the
drain if this bill is passed. The media companies want “interactive digital
devices” (i.e. computers) to be designed such that it’s impossible to
access copyrighted material, except through means that ensure copyright
violations don’t occur. I could imagine hardware designs that assure this,
although it’s unclear what the performance and engineering environment
impact is.

Jan

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

OSR_Community_User · September 20, 2001, 11:30pm

I found out about the existence of the SMM the hard way last year, when the BIOS
SMM handler did not properly work around an MCH bug dealing with ECC errors, and overwrote
a couple of bytes of HAL instructions on every corrected ECC error (as you might
guess, these do not occur in any discernable pattern). To debug this,
we ended up taking lots of liberties with NT. We changed the 4MB MMU to a
page of MMUs, and set the write protect bit, but it was still corrupted. So we
actually copied the data to another physical page, and proved the memory was being corrupted
by physical address. Then once we got it to fail before any of our drivers was loaded,
so we finally went locking elsewhere.

So to find a bug that was to due to this “hideous, irresponsible, architecturally aberrant, hack” we
did a number of hideous, irresponsible, architecturally aberrant, hacks. Imagine what we would have
done if we weren’t able to change the BIOS, but had to work around it. We would modify the
SMM register so that it would vector the SMM interrupt into our patch code before giving control
to the BIOS…

-DH

----- Original Message -----
From: “Jan Bottorff”
To: “NT Developers Interest List”
Sent: Thursday, September 20, 2001 8:55 PM
Subject: [ntdev] RE: disable interrupts

> At 11:03 AM 9/20/2001 -0400, you wrote:
> >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.
>
> If I’m not mistaken, fiddling with the IDT will NOT absolutely guarantee no
> interrupts. I believe you still could get system management mode
> interrupts, which are not routed through the IDT, but through a hidden
> register that is only accessible from SMM. My understanding is SMM is used
> for things like power management, and memory fault analysis. The BIOS will
> have a SMM handler that get’s invoked when certain events occur. This is
> under ANY OS or kernel code that thinks it has control of the CPU, and
> should be thought of as firmware that happens to use the normal CPU for
> execution.
>
> - Jan
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@syssoftsol.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

OSR_Community_User · September 21, 2001, 1:37am

I was thinking it might be a problem with MP machines as the IDT is a
per-processor entity. But, I guess it wouldn’t matter, as the old code
running on a separate processor while you are swapping in the new pointer
on a given processor shouldn’t matter. Well, shouldn’t matter aside from
the whole potentially walking on the world, stomping the OS, not being a
good neighbor problem. But that has already been dealt with fairly well so
I won’t pile on

Bill M.

On 09/20/01, ““Moreira, Alberto” ” wrote:

> It’s only one instruction, why disable interrupts ?
>
> Alberto.
>
> -----Original Message-----
> From: xxxxx@bsquare.com [mailto:xxxxx@bsquare.com]
> Sent: Wednesday, September 19, 2001 9:01 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: disable interrupts
>
>
> Wouldn’t you need to stop interrupts in order to frig the IDT(s)?
>
> Bill McKenzie
> Software Engineer
> bSquare Corporation
>

—
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

OSR_Community_User · September 21, 2001, 10:20am

Zoltan,

I manage development of SoftICE, BoundsChecker, and other 32-bit tools here
at Compuware Numega. My team and I, plus the DriverWorks/DriverNetworks
group who has a different manager, gave you DriverStudio 2.0, 2.01 and 2.5.

Alberto.

-----Original Message-----
From: xxxxx@yahoo.com [mailto:xxxxx@yahoo.com]
Sent: Thursday, September 20, 2001 6:24 PM
To: NT Developers Interest List
Subject: [ntdev] Re: disable interrupts

> … If every developer had your attitude, Windows would be
> even more unstable than it already is. I would highly recommend that no
one
> buy any products from you company, ever!

SoftICE is pretty good though

Alberto, are you working on the SoftICE project? (No offense, I’m just
curios)

Zoltan

Do You Yahoo!?

Get your free @yahoo.com address at http://mail.yahoo.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

OSR_Community_User · September 21, 2001, 6:47pm

Thanks Gary & Mark.

My earlier confusion was based on the understanding that Spin Locks can only
be acquired at DISPATCH_LEVEL. Now I know there is one special spin lock
that can be acquired at DIRQL.

So it makes sense now.

We want to define a layer of abstraction which can provide us a portable api
for doing things like KeSynchroniseExecution. As things stand right
now…looks if we provide two functions that can keep isr executions out
from critical parts of the code that would be nice. Is there a system call
in windows that can be used to acquire that ISR spin lock ?

We already have implemented a similar layer of abstraction for mutual
exclusion between threads using mutexes. And parhaps you too meant to say
that its a different issue than mutual exclusion from ISR.
I mean preventing a user thread and ISR manipulating the same data requires
different mechanism than the one between threads/processes. Am I right ?

In short, we want to define an api whose implementation may also be easy on
Linux. The way things are building up in my mind…I think writing a routine
that raises the IRQL to device IRQL and that can acquire a spin lock at
DIRQL with a matching routine that can do the opposite would probably solve
our problem in a relatively easy way.

Repeatin my question. Is it possible to acquire the ISR spin lock
independently from KeSynchroniseExecution. My only reservation about
KeSynchroniseExecution is that forces you to write your code in certain way.
Having two locking/unlocking functions feel more intuitive.

DoImakeAnySense ?

Hassan

From: “Mark Roddy”
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] RE: disable interrupts
>Date: Thu, 20 Sep 2001 20:52:04 -0400
>
>Gary has it about right. However, unless you are serializing direct
>access to the hardware, including access by your ISR, the interrupt
>object spinlock is not used for serialization, as it blocks other
>hardware interrupts, (potentially on all CPUS,) and has been made
>intentionally less than easy to use by the NT developers. Instead
>executive spinlocks, events, mutex objects, resource locks etc. provide
>a very rich set of tools for performing all sorts of serialization.
>
>Without knowing the details of your project, it is pretty much
>impossible to say what you need to use, other than to continue to
>observe that CLI/STI or KeRaiseIrql are not the right approach. The
>general way to decide which mechanism to use is to understand exactly
>what interrupt levels all code paths that need to be serialized run at.
>If the answer is PASSIVE_LEVEL (and more generally < DISPATCH_LEVEL)
>then the high level abstract serialization mechanisms are appropriate:
>resource locks, events, mutex and semaphore objects. If the answer is
>that some code paths may execute at DISPATCH_LEVEL, but the hardware ISR
>running at DIRQL is not involved, then the answer is an executive
>spinlock acquired/released through KeAcquire/KeReleaseSpinlock. If the
>answer is that you really do need to have serialization include your
>ISR, then KeSynchronizeExecution is the mechanism. In the latter case
>you may really have to look at this closely and separate the ISR cases
>from all other serialization issues. Read the DDK. Buy one of the
>several excellent books on NT kernel driver development.
>
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Gary Little
> > Sent: Thursday, September 20, 2001 8:02 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: disable interrupts
> >
> >
> > Mark kick me in the shins if I’m wrong on this one …
> >
> > Each IRQ is associated with an interrupt object, and within
> > that interrupt object is a spinlock. When a DIRQL event
> > (interrupt or a sync call) occurs, that spinlock is acquired.
> > If it is already acquired then the cpu spins until it is
> > free, and it then acquires it, process the interrupt and
> > releases the spinlock. That spinlock is either created for
> > you in IoConnectInterrupt, or you create it, initialize it,
> > and pass it to IoConnectInterrupt.
> >
> > Gary G. Little
> > Staff Engineer
> > Broadband Storage, Inc.
> > xxxxx@broadstor.com
> >
> > -----Original Message-----
> > From: Hassan I Khan [mailto:xxxxx@hotmail.com]
> > Sent: Thursday, September 20, 2001 4:28 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: disable interrupts
> >
> >
> >
> > >From: “Mark Roddy”
> > >Reply-To: “NT Developers Interest List”
> > >To: “NT Developers Interest List”
> > >Subject: [ntdev] RE: disable interrupts
> > >Date: Wed, 19 Sep 2001 22:26:32 -0400
> > >
> > >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.
> > >
> >
> > Sorry but I don’t know equivalent NT mechanism. Although I
> > did read about KeSynchroniseExecution (if thats what you re
> > referring to ) but I would really like to know what does
> > Windows do to achieve this. I mean how does windows prevent
> > execution of an ISR on one processor while it is already
> > executing on the other. Inspite of spending close to a year
> > on learning NT device drivers I still am a novice. So please
> > pardon these basic questions.
> >
> > Hassan
> >
> >
> > Get your FREE download of MSN Explorer at
> > http://explorer.msn.com/intl.asp
> >
> >
> > —
> > 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@hollistech.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

OSR_Community_User · September 22, 2001, 2:49pm

> I was told the only way to execute a critical section in Linux Kernel

(without doing too much) is to disable all interrupts.

Looks like this is a wrong way in Linux kernel too. The correct way is “with
doing too much”.

Anyway the 2 kernels have too different synchronization schemes (Linux is
more primitive) - so your task is rather hard.

Max

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

OSR_Community_User · September 23, 2001, 12:11pm

> in spite of the OS. If doing this kind of thing was hideous,
irresponsible,

architecturally aberrant, neither SoftIce nor BoundsChecker would work,
would they ?

Neither SI nor BoundsChecker are intended to run on production machines.
They are for testing machines only.

Max

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

OSR_Community_User · September 23, 2001, 12:11pm

> Sorry but I don’t know equivalent NT mechanism. Although I did read about

KeSynchroniseExecution (if thats what you re referring to ) but I would

Yes.
KeSynchroniseExecution is taking the spinlock associated with the interrupt.
Yes, the callback called by KeSynchroniseExecution will guarantee to not be
interrupted by the ISR in question - neither on the same CPU nor on any
other CPUs in the system.

The ISR cannot run while the callback runs - even on different CPU.

This guarantee is enforced on local CPU by masking the interrupt using PIC,
and on other CPUs by holding a spin lock (each interrupt has a spin lock
associated with it, and the ISR runs with this spinlock acquired).

Max

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

OSR_Community_User · September 23, 2001, 12:11pm

> register that is only accessible from SMM. My understanding is SMM is used

for things like power management

Yes, but on old pre-ACPI machines only like Compaq Presario of P5/MMX
generation.
This machine can sleep and awaken with NT4 running on it (i.e. without the
OS support).

Max

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

OSR_Community_User · September 23, 2001, 12:11pm

> It seems like unprotected kernel mode software development is down the

drain if this bill is passed. The media companies want “interactive
digital
devices” (i.e. computers) to be designed such that it’s impossible to
access copyrighted material, except through means that ensure copyright
violations don’t occur. I could imagine hardware designs that assure this,

Openness will be surely sacrificed for such, that’s why I don’t think
industry will move this way.
The tendention is towards 100% open Linux, not towards such devices.

And under any open OS - put a hook to TextOut to convert any protected text
to unprotected one. This will surely help.

I’m worried with this copyright histeria. IMHO the correct mean of enforcing
the copyright is hunting warez sites, and not the crack authors.
Hunting lockpick producers for thievery is a bit strange - better to hunt
thieves.

Max

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

RE: Re[2]: disable interrupts

How is a level-triggered interrupt acknowlegded with an IRET ? AFAIK the cpu blocks at that irql (and lower ones).

How is a level-triggered interrupt acknowlegded with an IRET ? AFAIK the cpu
blocks at that irql (and lower ones).