I used following two lines in my filesystem filter driver.
__asm cli
__asm sti
By the way, I got errors while compiling with 64 Bit Build Environment.
The error was ‘nonstandard extension used : ‘__asm’ keyword not supported in
this product’.
How should i solve this problem.
Thanks in advance!
You must not use these opcodes in a filesystem filter. Use some OS-provided
sync objects instead.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “csjung”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Monday, June 21, 2004 3:49 PM
Subject: [ntdev] Question about 64 Bit Build
> I used following two lines in my filesystem filter driver.
>
> asm cli
> asm sti
>
> By the way, I got errors while compiling with 64 Bit Build Environment.
> The error was ‘nonstandard extension used : ‘__asm’ keyword not supported in
> this product’.
>
> How should i solve this problem.
>
> Thanks in advance!
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
I may be wrong, but AFAIK the AMD64 Compiler doesn’t have an assembler. You
can write assembler code using Masm if you really need it.
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Monday, June 21, 2004 8:04 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Question about 64 Bit Build
You must not use these opcodes in a filesystem filter. Use some
OS-provided
sync objects instead.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “csjung”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Monday, June 21, 2004 3:49 PM
Subject: [ntdev] Question about 64 Bit Build
> I used following two lines in my filesystem filter driver.
>
> asm cli
> asm sti
>
> By the way, I got errors while compiling with 64 Bit Build Environment.
> The error was ‘nonstandard extension used : ‘__asm’ keyword not supported
in
> this product’.
>
> How should i solve this problem.
>
> Thanks in advance!
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.
Alberto,
That is correct, there is no support for inline assembler in the AMD64
version of the compiler. Apparently the wise people at Microsoft do not want
us to use inline assembler (presumably to avoid portability problems).
If you have a large chunk of code, this isn’t a big deal, just split it out
to an external function.
Small code snippets written in asembler can be a quick way to get something
done that is not supported by the compiler (or not WELL supported by the
compiler) however, and it would be very nice to be able to do this in inline
assembler.
A typical case of necessary use of inline assembler would be our
stack-switching when building our simulator driver[1], where we need to have
more stack-space than Microsoft donates for the driver. This is, in AMD64,
done by calling an external assembler routine that has 5 instructions in it
(fetch new stack, fetch return address, set stack pointer, push return
address, return), and in regular i386 uses two instructions, one to fetch a
new stack value, and one to set the stack pointer to the new value.
Note:
–
Mats
-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Monday, June 21, 2004 1:47 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Question about 64 Bit BuildI may be wrong, but AFAIK the AMD64 Compiler doesn’t have an
assembler. You
can write assembler code using Masm if you really need it.Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim
S. Shatskih
Sent: Monday, June 21, 2004 8:04 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Question about 64 Bit BuildYou must not use these opcodes in a filesystem filter. Use some
OS-provided
sync objects instead.Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com----- Original Message -----
From: “csjung”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Monday, June 21, 2004 3:49 PM
> Subject: [ntdev] Question about 64 Bit Build
>
>
> > I used following two lines in my filesystem filter driver.
> >
> > asm cli
> > asm sti
> >
> > By the way, I got errors while compiling with 64 Bit Build
> Environment.
> > The error was ‘nonstandard extension used : ‘__asm’ keyword
> not supported
> in
> > this product’.
> >
> > How should i solve this problem.
> >
> > Thanks in advance!
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@compuware.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> The contents of this e-mail are intended for the named
> addressee only. It
> contains information that may be confidential. Unless you are
> the named
> addressee or an authorized designee, you may not copy or use
> it, or disclose
> it to anyone else. If you received it in error please notify
> us immediately
> and then destroy it.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> 1. Before anyone attacks me: This is not a production driver, it’s a C++
simulated graphics chip that we use to test the driver before the real
I agree with you completely, but the OP was speaking about the filesystem
filter. Why use “cli” in it?
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> > 1. Before anyone attacks me: This is not a production
driver, it’s a C++
> simulated graphics chip that we use to test the driver
before the realI agree with you completely, but the OP was speaking about
the filesystem
filter. Why use “cli” in it?
To that I agree it’s probably not a good idea. Especially as it’s probably
not going to do what the OP wanted in the first instance, as CLI is not
going to work on Multiprocessor systems (well, it’s going to stop THAT
processor from taking interrupts), as another processor may be taking an
interrupt and thus potentially touching something that the OP wanted to
protect.
Of course, without a context, we can’t really say why the CLI was there, but
I agree completely that it’s most likely bad code…
–
Mats
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
One reason I see is to make sure that a spin loop isn’t interrupted by a
higher IRQL interrupt on the same processor. I know that you Windows guys
don’t like this idea very much, but I cannot get used to the idea that a
spinlock loop is interruptable !
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Monday, June 21, 2004 9:12 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Question about 64 Bit Build
- Before anyone attacks me: This is not a production driver, it’s a C++
simulated graphics chip that we use to test the driver before the real
I agree with you completely, but the OP was speaking about the filesystem
filter. Why use “cli” in it?
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.
> I agree with you completely, but the OP was speaking about the filesystem
filter. Why use “cli” in it?
To make sure it won’t work right on multiprocessor?
Loren
What is the need in such a thing in an FS filter?
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Moreira, Alberto”
To: “Windows System Software Devs Interest List”
Sent: Monday, June 21, 2004 5:17 PM
Subject: RE: [ntdev] Question about 64 Bit Build
> One reason I see is to make sure that a spin loop isn’t interrupted by a
> higher IRQL interrupt on the same processor. I know that you Windows guys
> don’t like this idea very much, but I cannot get used to the idea that a
> spinlock loop is interruptable !
>
> Alberto.
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
> Sent: Monday, June 21, 2004 9:12 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Question about 64 Bit Build
>
>
> > 1. Before anyone attacks me: This is not a production driver, it’s a C++
> > simulated graphics chip that we use to test the driver before the real
>
> I agree with you completely, but the OP was speaking about the filesystem
> filter. Why use “cli” in it?
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@compuware.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or disclose
> it to anyone else. If you received it in error please notify us immediately
> and then destroy it.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
A possibly silly point here but … “cli” and “sti” are op codes in 64 bit
processors? But then I have only looked at the Itanium where “cli” and “sti”
are NOT opcodes … at least when I have looked. But no, there is no in line
assembly in the current C compiler for 64 bit work.
There is very little justification, other than the “I can do it better ego
trip” in XP and above, to use assembly, and I can almost guarantee it will
in the long run prove to be nary as efficient as what is currently provided
by the DDK compiler.
–
Gary G. Little
Seagate Technologies, LLC
“csjung” wrote in message news:xxxxx@ntdev…
> I used following two lines in my filesystem filter driver.
>
> asm cli
> asm sti
>
> By the way, I got errors while compiling with 64 Bit Build Environment.
> The error was ‘nonstandard extension used : ‘__asm’ keyword not supported
in
> this product’.
>
> How should i solve this problem.
>
> Thanks in advance!
>
>
>
> A possibly silly point here but … “cli” and “sti” are op
codes in 64 bit
processors? But then I have only looked at the Itanium where
“cli” and “sti”
are NOT opcodes … at least when I have looked. But no,
there is no in line
assembly in the current C compiler for 64 bit work.
They would be valid instructions in AMD64, as it’s got almost a full set of
386 opcodes + all the additions made in 486, Pentium(MMX) and SSE/SSE2
instructions. It’s only missing a few of the really obscure opcodes, like
“AAA”, “AAS” and related, as well as the now fairly useless XLAT
instruction. I think a few others went in the bin too while they designed
the x86-64 instruction set. They also removed the single-byte versions of
PUSH/POP, which are duplicated in a double byte version.
The single byte opcode PUSH/POP instruction is, in 64-bit mode, used for the
Register Extension Prefix, a.k.a REX. This REX prefix is used to address the
extra 8 registers and to allow the use of 64-bit registers in src, target
and index.
–
Mats
Windows not being a real-time OS (c.f. that flamewar), it’s not
*supposed* to matter if you’re interrupted by something that doesn’t
share your resources.
If it *does* share your resources, it needs to share your
synchronization primitive (obviously :-). So that wouldn’t be a problem
either.
Moreira, Alberto wrote:
One reason I see is to make sure that a spin loop isn’t interrupted by a
higher IRQL interrupt on the same processor. I know that you Windows guys
don’t like this idea very much, but I cannot get used to the idea that a
spinlock loop is interruptable !Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Monday, June 21, 2004 9:12 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Question about 64 Bit Build>1. Before anyone attacks me: This is not a production driver, it’s a C++
>simulated graphics chip that we use to test the driver before the realI agree with you completely, but the OP was speaking about the filesystem
filter. Why use “cli” in it?Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.comThe contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.
–
…/ray..
Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.
Well, I have run into situations in this very mailing list where a spinlock
did not guarantee mutual exclusion on a unit-processor system, because there
was always the possibility that some interrupt at a higher IRQL grabbed the
same resource and hence caused a deadlock or something just as evil. So, my
point is, a sequence such as
pushf/cli/while(test and set)/popf
will guarantee that nobody will seize control of that processor while it’s
spinning, which at least is the kind of semantics that I’m used to ascribe
to a spinlock. In other words, if I’m inside my mutual-exclusion resource, I
don’t want any other process in the same machine to interrupt me and try to
grab my resource.
I may be wrong, but I believe a spinlock loop should be uninterruptible.
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Ray Trent
Sent: Monday, June 21, 2004 4:06 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Question about 64 Bit Build
Windows not being a real-time OS (c.f. that flamewar), it’s not
*supposed* to matter if you’re interrupted by something that doesn’t
share your resources.
If it *does* share your resources, it needs to share your
synchronization primitive (obviously :-). So that wouldn’t be a problem
either.
Moreira, Alberto wrote:
One reason I see is to make sure that a spin loop isn’t interrupted by a
higher IRQL interrupt on the same processor. I know that you Windows guys
don’t like this idea very much, but I cannot get used to the idea that a
spinlock loop is interruptable !Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Monday, June 21, 2004 9:12 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Question about 64 Bit Build>1. Before anyone attacks me: This is not a production driver, it’s a C++
>simulated graphics chip that we use to test the driver before the realI agree with you completely, but the OP was speaking about the filesystem
filter. Why use “cli” in it?Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.comThe contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or
disclose
it to anyone else. If you received it in error please notify us
immediately
and then destroy it.
–
…/ray..
Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.
NMI & SMI/SCI do not obey the CLI/STI model, I think, so they would be
useless to try and retain physical control of the processor. A spinlock can
be interrupted by normal interrupts, but most of the processing of
interrupts is usually reserved to later and not done in the ISR. Some
drivers do too much and when they try to create pseudo-real-time attributes
for some piece of hardware, they may do too much processing at DIRQL.
“Moreira, Alberto” wrote in message
news:xxxxx@ntdev…
> Well, I have run into situations in this very mailing list where a
spinlock
> did not guarantee mutual exclusion on a unit-processor system, because
there
> was always the possibility that some interrupt at a higher IRQL grabbed
the
> same resource and hence caused a deadlock or something just as evil. So,
my
> point is, a sequence such as
>
> pushf/cli/while(test and set)/popf
>
> will guarantee that nobody will seize control of that processor while it’s
> spinning, which at least is the kind of semantics that I’m used to ascribe
> to a spinlock. In other words, if I’m inside my mutual-exclusion resource,
I
> don’t want any other process in the same machine to interrupt me and try
to
> grab my resource.
>
> I may be wrong, but I believe a spinlock loop should be uninterruptible.
>
>
> Alberto.
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Ray Trent
> Sent: Monday, June 21, 2004 4:06 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Question about 64 Bit Build
>
>
> Windows not being a real-time OS (c.f. that flamewar), it’s not
> supposed to matter if you’re interrupted by something that doesn’t
> share your resources.
>
> If it does share your resources, it needs to share your
> synchronization primitive (obviously :-). So that wouldn’t be a problem
> either.
>
> Moreira, Alberto wrote:
>
> > One reason I see is to make sure that a spin loop isn’t interrupted by a
> > higher IRQL interrupt on the same processor. I know that you Windows
guys
> > don’t like this idea very much, but I cannot get used to the idea that a
> > spinlock loop is interruptable !
> >
> > Alberto.
> >
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
> > Sent: Monday, June 21, 2004 9:12 AM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] Question about 64 Bit Build
> >
> >
> >
> >>1. Before anyone attacks me: This is not a production driver, it’s a C++
> >>simulated graphics chip that we use to test the driver before the real
> >
> >
> > I agree with you completely, but the OP was speaking about the
filesystem
> > filter. Why use “cli” in it?
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@compuware.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> > The contents of this e-mail are intended for the named addressee only.
It
> > contains information that may be confidential. Unless you are the named
> > addressee or an authorized designee, you may not copy or use it, or
> disclose
> > it to anyone else. If you received it in error please notify us
> immediately
> > and then destroy it.
> >
> >
>
> –
> …/ray..
>
> Please remove “.spamblock” from my email address if you need to contact
> me outside the newsgroup.
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@compuware.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or
disclose
> it to anyone else. If you received it in error please notify us
immediately
> and then destroy it.
>
>
I suspect that alberto’s specific concern was that the resource he
wanted to control access to was the processor and not a data structure
or a piece of external hardware - something like the IDT which is used
in interrupt handling.
That’s just a guess though.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David J. Craig
Sent: Monday, June 21, 2004 2:07 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Question about 64 Bit Build
NMI & SMI/SCI do not obey the CLI/STI model, I think, so they would be
useless to try and retain physical control of the processor. A spinlock
can be interrupted by normal interrupts, but most of the processing of
interrupts is usually reserved to later and not done in the ISR. Some
drivers do too much and when they try to create pseudo-real-time
attributes for some piece of hardware, they may do too much processing
at DIRQL.
“Moreira, Alberto” wrote in message
news:xxxxx@ntdev…
> Well, I have run into situations in this very mailing list where a
spinlock
> did not guarantee mutual exclusion on a unit-processor system, because
there
> was always the possibility that some interrupt at a higher IRQL
> grabbed
the
> same resource and hence caused a deadlock or something just as evil.
> So,
my
> point is, a sequence such as
>
> pushf/cli/while(test and set)/popf
>
> will guarantee that nobody will seize control of that processor while
> it’s spinning, which at least is the kind of semantics that I’m used
> to ascribe to a spinlock. In other words, if I’m inside my
> mutual-exclusion resource,
I
> don’t want any other process in the same machine to interrupt me and
> try
to
> grab my resource.
>
> I may be wrong, but I believe a spinlock loop should be
uninterruptible.
>
>
> Alberto.
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Ray Trent
> Sent: Monday, June 21, 2004 4:06 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Question about 64 Bit Build
>
>
> Windows not being a real-time OS (c.f. that flamewar), it’s not
> supposed to matter if you’re interrupted by something that doesn’t
> share your resources.
>
> If it does share your resources, it needs to share your
> synchronization primitive (obviously :-). So that wouldn’t be a
> problem either.
>
> Moreira, Alberto wrote:
>
> > One reason I see is to make sure that a spin loop isn’t interrupted
> > by a higher IRQL interrupt on the same processor. I know that you
> > Windows
guys
> > don’t like this idea very much, but I cannot get used to the idea
> > that a spinlock loop is interruptable !
> >
> > Alberto.
> >
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S.
> > Shatskih
> > Sent: Monday, June 21, 2004 9:12 AM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] Question about 64 Bit Build
> >
> >
> >
> >>1. Before anyone attacks me: This is not a production driver, it’s a
> >>C++ simulated graphics chip that we use to test the driver before
> >>the real
> >
> >
> > I agree with you completely, but the OP was speaking about the
filesystem
> > filter. Why use “cli” in it?
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> > xxxxx@compuware.com To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
> >
> >
> > The contents of this e-mail are intended for the named addressee
only.
It
> > contains information that may be confidential. Unless you are the
> > named addressee or an authorized designee, you may not copy or use
> > it, or
> disclose
> > it to anyone else. If you received it in error please notify us
> immediately
> > and then destroy it.
> >
> >
>
> –
> …/ray..
>
> Please remove “.spamblock” from my email address if you need to
> contact me outside the newsgroup.
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@compuware.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
>
> The contents of this e-mail are intended for the named addressee only.
> It contains information that may be confidential. Unless you are the
> named addressee or an authorized designee, you may not copy or use it,
> or
disclose
> it to anyone else. If you received it in error please notify us
immediately
> and then destroy it.
>
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Which is, of course, one of the main reasons why Windows isn’t a
real-time operating system. The whole point of the IRQL design is to
allow higher-priority interrupts to interrupt lower priority interrupts.
If the higher priority interrupt is sharing your resource, you should be
synchronizing execution with *that* ISR ('s spinlock), and not another
ISR or another non-DIRQL spin-lock.
Moreira, Alberto wrote:
Well, I have run into situations in this very mailing list where a spinlock
did not guarantee mutual exclusion on a unit-processor system, because there
was always the possibility that some interrupt at a higher IRQL grabbed the
same resource and hence caused a deadlock or something just as evil. So, my
point is, a sequence such aspushf/cli/while(test and set)/popf
will guarantee that nobody will seize control of that processor while it’s
spinning, which at least is the kind of semantics that I’m used to ascribe
to a spinlock. In other words, if I’m inside my mutual-exclusion resource, I
don’t want any other process in the same machine to interrupt me and try to
grab my resource.I may be wrong, but I believe a spinlock loop should be uninterruptible.
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Ray Trent
Sent: Monday, June 21, 2004 4:06 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Question about 64 Bit BuildWindows not being a real-time OS (c.f. that flamewar), it’s not
*supposed* to matter if you’re interrupted by something that doesn’t
share your resources.If it *does* share your resources, it needs to share your
synchronization primitive (obviously :-). So that wouldn’t be a problem
either.Moreira, Alberto wrote:
>One reason I see is to make sure that a spin loop isn’t interrupted by a
>higher IRQL interrupt on the same processor. I know that you Windows guys
>don’t like this idea very much, but I cannot get used to the idea that a
>spinlock loop is interruptable !
>
>Alberto.
>
>
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
>Sent: Monday, June 21, 2004 9:12 AM
>To: Windows System Software Devs Interest List
>Subject: Re: [ntdev] Question about 64 Bit Build
>
>
>
>
>>1. Before anyone attacks me: This is not a production driver, it’s a C++
>>simulated graphics chip that we use to test the driver before the real
>
>
>I agree with you completely, but the OP was speaking about the filesystem
>filter. Why use “cli” in it?
>
>Maxim Shatskih, Windows DDK MVP
>StorageCraft Corporation
>xxxxx@storagecraft.com
>http://www.storagecraft.com
>
>
>—
>Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as: xxxxx@compuware.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>The contents of this e-mail are intended for the named addressee only. It
>contains information that may be confidential. Unless you are the named
>addressee or an authorized designee, you may not copy or use it, ordisclose
>it to anyone else. If you received it in error please notify us
immediately
>and then destroy it.
>
>
–
…/ray..
Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.