Driver Design and Data Integrity

NTDEV
1

I have a board that reads radar image data. The radar sweep is divided
into 2048 sectors. Each time a new sector is ready, the board interrupts
and my driver DMAs that sector’s data into a buffer provided by the
application. It all works.

The board has a register containing the number of the sector whose data
was just DMA’d. My driver provides an IOCTL to read this register. All
well and good.

EXCEPT, the ugly user, who is in my company and thus thinks he can
influence the driver design, doesn’t want to poll this register. He wants
to pass my driver a pointer to a memory location, and wants the driver to
write the 4-byte sector number during each DPC for ISR.

Who else thinks this is a crummy design? Or a good idea? Is there any
danger of the app getting a bad value because it reads part of the value
and the driver updates the other part?

Thanks for any ammunition to use against the user!
john.

2

Hi,

Isn’t it enough if the application gets notified every time new sector data
is DMAd into application buffer (as the sector number changes at the same
moment)?
How have you implemented the operation of copying data into app’s memory -
as an IOCTL that waits until the data
is available or is it done completely asynchronously (the app just gives a
pointer and then the driver fills the buffer every time the interrupt
occurs)?
I’m asking because the best way to avoid polling is to implement some
blocking mechanism. Without it, even if you provided a way for updating some
variable in the app space when the sector number changes, the user would
have to poll for the value of this variable…

Regards,
Rafal

----- Original Message -----
From: “John Reilly”
To: “NT Developers Interest List”
Sent: Tuesday, January 21, 2003 2:15 PM
Subject: [ntdev] Driver Design and Data Integrity

> I have a board that reads radar image data. The radar sweep is divided
> into 2048 sectors. Each time a new sector is ready, the board interrupts
> and my driver DMAs that sector’s data into a buffer provided by the
> application. It all works.
>
> The board has a register containing the number of the sector whose data
> was just DMA’d. My driver provides an IOCTL to read this register. All
> well and good.
>
> EXCEPT, the ugly user, who is in my company and thus thinks he can
> influence the driver design, doesn’t want to poll this register. He wants
> to pass my driver a pointer to a memory location, and wants the driver to
> write the 4-byte sector number during each DPC for ISR.
>
> Who else thinks this is a crummy design? Or a good idea? Is there any
> danger of the app getting a bad value because it reads part of the value
> and the driver updates the other part?
>
> Thanks for any ammunition to use against the user!
> john.
>
> —
> You are currently subscribed to ntdev as: xxxxx@poczta.onet.pl
> To unsubscribe send a blank email to xxxxx@lists.osr.com

3

If the user’s memory location (at say address X) is in user space, it’s
definitely a bad design. It’s nondeterministic what process will be current
when the DPC executes. Three interesting cases: 1. The user’s process
happens to be the current process on the processor executing the DPC and the
memory location happens to be valid (or you locked it), so the memory
location will be updated just fine. 2. It’s a different process with valid
memory at address X: the driver will corrupt that memory, writing the sector
number over some random data (or code). 3. The current process’s memory
address X isn’t valid –> bugcheck.

Another concern is timing. It could happen that under load, the app doesn’t
poll the sector number value until after the next sector is being processed.

How about eliminating the IOCTL and storing the sector number and the sector
data together in an associated data structure? Could the driver initiate
the DMA of the sector data and then write the sector number to the sector
number field associated with the sector data?

regards

-Tom Stonecypher

Tom Stonecypher
xxxxx@iStreamConsulting.com
www.iStreamConsulting.com
+1-803-463-6340

“John Reilly” wrote in message news:xxxxx@ntdev…
>
> I have a board that reads radar image data. The radar sweep is divided
> into 2048 sectors. Each time a new sector is ready, the board interrupts
> and my driver DMAs that sector’s data into a buffer provided by the
> application. It all works.
>
> The board has a register containing the number of the sector whose data
> was just DMA’d. My driver provides an IOCTL to read this register. All
> well and good.
>
> EXCEPT, the ugly user, who is in my company and thus thinks he can
> influence the driver design, doesn’t want to poll this register. He wants
> to pass my driver a pointer to a memory location, and wants the driver to
> write the 4-byte sector number during each DPC for ISR.
>
> Who else thinks this is a crummy design? Or a good idea? Is there any
> danger of the app getting a bad value because it reads part of the value
> and the driver updates the other part?
>
> Thanks for any ammunition to use against the user!
> john.
>
>

4

If your 4 byte is the only data transfered from driver to user, and this is
performed
by “one” intel assembler instruction ( i.e mov base:[offset], eax ), and
your on a
mono-processor, the transfer must be reliable. On a European multiprocessor
system of the early '90 ties, we called this “coordinated by hardware”. On
those
early bird machines , there was a hardware bus lock that prevented two
processors
from accessing the same piece of memory within one instruction by
serializing the
access. I don’t know how multiprocessor Intel processor systems manage this.

I assume you know all about sharing memory between kernel and user mode,
thus
this would be off topic…

----- Original Message -----
From: “John Reilly”
To: “NT Developers Interest List”
Sent: Tuesday, January 21, 2003 2:15 PM
Subject: [ntdev] Driver Design and Data Integrity

> I have a board that reads radar image data. The radar sweep is divided
> into 2048 sectors. Each time a new sector is ready, the board interrupts
> and my driver DMAs that sector’s data into a buffer provided by the
> application. It all works.
>
> The board has a register containing the number of the sector whose data
> was just DMA’d. My driver provides an IOCTL to read this register. All
> well and good.
>
> EXCEPT, the ugly user, who is in my company and thus thinks he can
> influence the driver design, doesn’t want to poll this register. He wants
> to pass my driver a pointer to a memory location, and wants the driver to
> write the 4-byte sector number during each DPC for ISR.
>
> Who else thinks this is a crummy design? Or a good idea? Is there any
> danger of the app getting a bad value because it reads part of the value
> and the driver updates the other part?
>
> Thanks for any ammunition to use against the user!
> john.
>
> —
> You are currently subscribed to ntdev as: xxxxx@compaqnet.be
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

5

Better stated:

Make a data structure something like this:
struct Ring_Entry {
ULONG iSectorNumber;
BYTE bSectorData[LENGTH];
}

Map the data structure into system space so that you can write to it from
within a DPC context.

When a new sector comes in, write the sector number using the system space
mapping, then schedule the DMA. When the DMA is complete, inform the app
that new data is available.

My earlier points about memory validity were incorrect - your driver would
just do a system-space mapping of the user’s buffer. The timing issue,
which you raise, remains as a significant issue with the user’s design. A
buffer which includes the sector number, like I’ve outlined above, should
address the timing issue, but you probably need to build a ring of such
buffers to avoid buffer starvation under load.

Tom Stonecypher
xxxxx@iStreamConsulting.com
www.iStreamConsulting.com
+1-803-463-6340

“Tom Stonecypher” wrote in message
news:xxxxx@ntdev…
>
> If the user’s memory location (at say address X) is in user space, it’s
> definitely a bad design. It’s nondeterministic what process will be
current
> when the DPC executes. Three interesting cases: 1. The user’s process
> happens to be the current process on the processor executing the DPC and
the
> memory location happens to be valid (or you locked it), so the memory
> location will be updated just fine. 2. It’s a different process with
valid
> memory at address X: the driver will corrupt that memory, writing the
sector
> number over some random data (or code). 3. The current process’s memory
> address X isn’t valid –> bugcheck.
>
> Another concern is timing. It could happen that under load, the app
doesn’t
> poll the sector number value until after the next sector is being
processed.
>
> How about eliminating the IOCTL and storing the sector number and the
sector
> data together in an associated data structure? Could the driver initiate
> the DMA of the sector data and then write the sector number to the sector
> number field associated with the sector data?
>
> regards
>
> -Tom Stonecypher
>
> Tom Stonecypher
> xxxxx@iStreamConsulting.com
> www.iStreamConsulting.com
> +1-803-463-6340
>
>
> “John Reilly” wrote in message news:xxxxx@ntdev…
> >
> > I have a board that reads radar image data. The radar sweep is divided
> > into 2048 sectors. Each time a new sector is ready, the board
interrupts
> > and my driver DMAs that sector’s data into a buffer provided by the
> > application. It all works.
> >
> > The board has a register containing the number of the sector whose data
> > was just DMA’d. My driver provides an IOCTL to read this register. All
> > well and good.
> >
> > EXCEPT, the ugly user, who is in my company and thus thinks he can
> > influence the driver design, doesn’t want to poll this register. He
wants
> > to pass my driver a pointer to a memory location, and wants the driver
to
> > write the 4-byte sector number during each DPC for ISR.
> >
> > Who else thinks this is a crummy design? Or a good idea? Is there any
> > danger of the app getting a bad value because it reads part of the value
> > and the driver updates the other part?
> >
> > Thanks for any ammunition to use against the user!
> > john.
> >
> >
>
>
>
>

6

xxxxx@sneakemail.com said:

I have a board that reads radar image data. The radar sweep is
divided into 2048 sectors. Each time a new sector is ready, the board
interrupts and my driver DMAs that sector’s data into a buffer
provided by the application. It all works.

Polling is evil, but what you described as the user’s request is
just as bad. If I were doing this, I would use a DeviceIoControl
to read the next sector number. This would *block* until the
sector is ready, and when it returns would write the sector number
into the buffer supplied by the user. (Overlapped IO would work
with this.)

This remains synchronized, the transfer of the data is safe, and
it should be very simple for the user mode programmer to use this.

This interface would in fact allow the driver to keep a queue
of completed sectors. This would be a good thing, as I imagine
radar data arrives when it will, and a queue can absorb bursts
without data loss.

Steve Williams “The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”

7

Actually, on second thought, rather a dumb idea thought up by a rather lazy
application geek who couldn’t find his/her/its ass if he/she/it were sitting
on it. And you may quote me.

Yes … you writing to it in a DPC will ensure you’re synchronization. But
there is nothing he/she/it can do that will ensure that you can’t clobber
the value while he/she/it is accessing it. There are no “spinlocks” they can
hold that will prevent IRQL from going to DIRQL, then falling back to
DISPATCH_LEVEL which will then allow your DPC to run where you will merrily
dump all over the data he/she/it was accessing. What is worse is this …
you update it and the app then writes over your update. He/she/it will then
run around mewling and whining about how you missed an interrupt.

Oh … and there was no mention I saw about cache lines getting royally
hosed.

The best idea is using a asyncrnous IO in a device IOCTL. But App probably
won;t like that since he/she/it will have some work to do. :slight_smile:

–
Gary G. Little
Have Computer, Will Travel …
909-698-3191
909-551-2105

“John Reilly” wrote in message news:xxxxx@ntdev…
>
> I have a board that reads radar image data. The radar sweep is divided
> into 2048 sectors. Each time a new sector is ready, the board interrupts
> and my driver DMAs that sector’s data into a buffer provided by the
> application. It all works.
>
> The board has a register containing the number of the sector whose data
> was just DMA’d. My driver provides an IOCTL to read this register. All
> well and good.
>
> EXCEPT, the ugly user, who is in my company and thus thinks he can
> influence the driver design, doesn’t want to poll this register. He wants
> to pass my driver a pointer to a memory location, and wants the driver to
> write the 4-byte sector number during each DPC for ISR.
>
> Who else thinks this is a crummy design? Or a good idea? Is there any
> danger of the app getting a bad value because it reads part of the value
> and the driver updates the other part?
>
> Thanks for any ammunition to use against the user!
> john.
>
>

8

I would consider pending multiple overlapped IOCTLs to the driver and
have UM threads (start with something like 16 threads) to wait on these
pended IOCTLs. When the driver has some data, it should fill in a data
structure (your sector number) and complete one of the pended IOCTLs.
Since you data is very small, you can send multiple sector numbers in
one IOCTL. Suppose that you get several sectors of data before you go
and post the data to the IOCTL and complete it… If you send in a MAX
count sized buffer on the pended IOCTL, you can send a chunk of sectors
numbers in one operation.

You will find that this is a very efficient and manageable mechanism to
accomplish your desired task. It is half of your design and half the
ugly user design.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Tuesday, January 21, 2003 11:45 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Driver Design and Data Integrity

Actually, on second thought, rather a dumb idea thought up by a rather
lazy
application geek who couldn’t find his/her/its ass if he/she/it were
sitting
on it. And you may quote me.

Yes … you writing to it in a DPC will ensure you’re synchronization.
But
there is nothing he/she/it can do that will ensure that you can’t
clobber
the value while he/she/it is accessing it. There are no “spinlocks” they
can
hold that will prevent IRQL from going to DIRQL, then falling back to
DISPATCH_LEVEL which will then allow your DPC to run where you will
merrily
dump all over the data he/she/it was accessing. What is worse is this
…
you update it and the app then writes over your update. He/she/it will
then
run around mewling and whining about how you missed an interrupt.

Oh … and there was no mention I saw about cache lines getting royally
hosed.

The best idea is using a asyncrnous IO in a device IOCTL. But App
probably
won;t like that since he/she/it will have some work to do. :slight_smile:

–
Gary G. Little
Have Computer, Will Travel …
909-698-3191
909-551-2105

“John Reilly” wrote in message
news:xxxxx@ntdev…
>
> I have a board that reads radar image data. The radar sweep is
divided
> into 2048 sectors. Each time a new sector is ready, the board
interrupts
> and my driver DMAs that sector’s data into a buffer provided by the
> application. It all works.
>
> The board has a register containing the number of the sector whose
data
> was just DMA’d. My driver provides an IOCTL to read this register.
All
> well and good.
>
> EXCEPT, the ugly user, who is in my company and thus thinks he can
> influence the driver design, doesn’t want to poll this register. He
wants
> to pass my driver a pointer to a memory location, and wants the driver
to
> write the 4-byte sector number during each DPC for ISR.
>
> Who else thinks this is a crummy design? Or a good idea? Is there
any
> danger of the app getting a bad value because it reads part of the
value
> and the driver updates the other part?
>
> Thanks for any ammunition to use against the user!
> john.
>
>

—
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

9

As long as we don’t exactly know what “he-her-it” has
in mind with the direct access of the 4-byte sector
number, we should make a restrictive approach. If the
goal to reach is simplicity and performance, John’s
driver could fire an event to a user thread waiting
at high priority, from within the DPC and after update
of the 4-byte field. If the application cannot manage
this event before the next interrupt occurs, other
proposed schemes won’t do this neither. I’ve just a
feeling that the application has to “show” something
with exactly the same rythmus as the occurrence of the
interrupts. I hope they won’t play DVD-movies and surf
the internet all at the same time on that machine ( LOL )
…

----- Original Message -----
From: “Gary G. Little”
Newsgroups: ntdev
To: “NT Developers Interest List”
Sent: Tuesday, January 21, 2003 8:45 PM
Subject: [ntdev] Re: Driver Design and Data Integrity

> Actually, on second thought, rather a dumb idea thought up by a rather
lazy
> application geek who couldn’t find his/her/its ass if he/she/it were
sitting
> on it. And you may quote me.
>
> Yes … you writing to it in a DPC will ensure you’re synchronization. But
> there is nothing he/she/it can do that will ensure that you can’t clobber
> the value while he/she/it is accessing it. There are no “spinlocks” they
can
> hold that will prevent IRQL from going to DIRQL, then falling back to
> DISPATCH_LEVEL which will then allow your DPC to run where you will
merrily
> dump all over the data he/she/it was accessing. What is worse is this …
> you update it and the app then writes over your update. He/she/it will
then
> run around mewling and whining about how you missed an interrupt.
>
> Oh … and there was no mention I saw about cache lines getting royally
> hosed.
>
> The best idea is using a asyncrnous IO in a device IOCTL. But App probably
> won;t like that since he/she/it will have some work to do. :slight_smile:
>
> –
> Gary G. Little
> Have Computer, Will Travel …
> 909-698-3191
> 909-551-2105
>
> “John Reilly” wrote in message news:xxxxx@ntdev…
> >
> > I have a board that reads radar image data. The radar sweep is divided
> > into 2048 sectors. Each time a new sector is ready, the board
interrupts
> > and my driver DMAs that sector’s data into a buffer provided by the
> > application. It all works.
> >
> > The board has a register containing the number of the sector whose data
> > was just DMA’d. My driver provides an IOCTL to read this register. All
> > well and good.
> >
> > EXCEPT, the ugly user, who is in my company and thus thinks he can
> > influence the driver design, doesn’t want to poll this register. He
wants
> > to pass my driver a pointer to a memory location, and wants the driver
to
> > write the 4-byte sector number during each DPC for ISR.
> >
> > Who else thinks this is a crummy design? Or a good idea? Is there any
> > danger of the app getting a bad value because it reads part of the value
> > and the driver updates the other part?
> >
> > Thanks for any ammunition to use against the user!
> > john.
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@compaqnet.be
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

10

In what manner is DMA data buffer provided by application?

----- Original Message -----
From: “John Reilly”
To: “NT Developers Interest List”
Sent: Tuesday, January 21, 2003 2:15 PM
Subject: [ntdev] Driver Design and Data Integrity

> I have a board that reads radar image data. The radar sweep is divided
> into 2048 sectors. Each time a new sector is ready, the board interrupts
> and my driver DMAs that sector’s data into a buffer provided by the
> application. It all works.
>
> The board has a register containing the number of the sector whose data
> was just DMA’d. My driver provides an IOCTL to read this register. All
> well and good.
>
> EXCEPT, the ugly user, who is in my company and thus thinks he can
> influence the driver design, doesn’t want to poll this register. He wants
> to pass my driver a pointer to a memory location, and wants the driver to
> write the 4-byte sector number during each DPC for ISR.
>
> Who else thinks this is a crummy design? Or a good idea? Is there any
> danger of the app getting a bad value because it reads part of the value
> and the driver updates the other part?
>
> Thanks for any ammunition to use against the user!
> john.
>
> —
> You are currently subscribed to ntdev as: xxxxx@epost.de
> To unsubscribe send a blank email to xxxxx@lists.osr.com

11

Yes but one UM thread is enough. Several overlapped IOCTLs (up to 64) can be
passed to driver and WaitForMultipleObjects can be used for waiting for
overlapped events. When driver completes an IRP, UM thread processed it,
passes new request to driver and waits again.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

From: xxxxx@storagecraft.com[SMTP:xxxxx@storagecraft.com]
Reply To: xxxxx@lists.osr.com
Sent: Tuesday, January 21, 2003 9:09 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: Driver Design and Data Integrity

I would consider pending multiple overlapped IOCTLs to the driver and
have UM threads (start with something like 16 threads) to wait on these
pended IOCTLs. When the driver has some data, it should fill in a data
structure (your sector number) and complete one of the pended IOCTLs.
Since you data is very small, you can send multiple sector numbers in
one IOCTL. Suppose that you get several sectors of data before you go
and post the data to the IOCTL and complete it… If you send in a MAX
count sized buffer on the pended IOCTL, you can send a chunk of sectors
numbers in one operation.

You will find that this is a very efficient and manageable mechanism to
accomplish your desired task. It is half of your design and half the
ugly user design.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Tuesday, January 21, 2003 11:45 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Driver Design and Data Integrity

Actually, on second thought, rather a dumb idea thought up by a rather
lazy
application geek who couldn’t find his/her/its ass if he/she/it were
sitting
on it. And you may quote me.

Yes … you writing to it in a DPC will ensure you’re synchronization.
But
there is nothing he/she/it can do that will ensure that you can’t
clobber
the value while he/she/it is accessing it. There are no “spinlocks” they
can
hold that will prevent IRQL from going to DIRQL, then falling back to
DISPATCH_LEVEL which will then allow your DPC to run where you will
merrily
dump all over the data he/she/it was accessing. What is worse is this
…
you update it and the app then writes over your update. He/she/it will
then
run around mewling and whining about how you missed an interrupt.

Oh … and there was no mention I saw about cache lines getting royally
hosed.

The best idea is using a asyncrnous IO in a device IOCTL. But App
probably
won;t like that since he/she/it will have some work to do. :slight_smile:

–
Gary G. Little
Have Computer, Will Travel …
909-698-3191
909-551-2105

“John Reilly” wrote in message
> news:xxxxx@ntdev…
> >
> > I have a board that reads radar image data. The radar sweep is
> divided
> > into 2048 sectors. Each time a new sector is ready, the board
> interrupts
> > and my driver DMAs that sector’s data into a buffer provided by the
> > application. It all works.
> >
> > The board has a register containing the number of the sector whose
> data
> > was just DMA’d. My driver provides an IOCTL to read this register.
> All
> > well and good.
> >
> > EXCEPT, the ugly user, who is in my company and thus thinks he can
> > influence the driver design, doesn’t want to poll this register. He
> wants
> > to pass my driver a pointer to a memory location, and wants the driver
> to
> > write the 4-byte sector number during each DPC for ISR.
> >
> > Who else thinks this is a crummy design? Or a good idea? Is there
> any
> > danger of the app getting a bad value because it reads part of the
> value
> > and the driver updates the other part?
> >
> > Thanks for any ammunition to use against the user!
> > john.
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> You are currently subscribed to ntdev as: michal.vodicka@st.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

12

Yes, but it is still in one thread of execution. I guess it depends on
the requirements.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Tuesday, January 21, 2003 2:23 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Driver Design and Data Integrity

Yes but one UM thread is enough. Several overlapped IOCTLs (up to 64)
can be
passed to driver and WaitForMultipleObjects can be used for waiting for
overlapped events. When driver completes an IRP, UM thread processed it,
passes new request to driver and waits again.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

From: xxxxx@storagecraft.com[SMTP:xxxxx@storagecraft.com]
Reply To: xxxxx@lists.osr.com
Sent: Tuesday, January 21, 2003 9:09 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: Driver Design and Data Integrity

I would consider pending multiple overlapped IOCTLs to the driver and
have UM threads (start with something like 16 threads) to wait on
these
pended IOCTLs. When the driver has some data, it should fill in a data
structure (your sector number) and complete one of the pended IOCTLs.
Since you data is very small, you can send multiple sector numbers in
one IOCTL. Suppose that you get several sectors of data before you go
and post the data to the IOCTL and complete it… If you send in a MAX
count sized buffer on the pended IOCTL, you can send a chunk of
sectors
numbers in one operation.

You will find that this is a very efficient and manageable mechanism
to
accomplish your desired task. It is half of your design and half the
ugly user design.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Tuesday, January 21, 2003 11:45 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Driver Design and Data Integrity

Actually, on second thought, rather a dumb idea thought up by a rather
lazy
application geek who couldn’t find his/her/its ass if he/she/it were
sitting
on it. And you may quote me.

Yes … you writing to it in a DPC will ensure you’re synchronization.
But
there is nothing he/she/it can do that will ensure that you can’t
clobber
the value while he/she/it is accessing it. There are no “spinlocks”
they
can
hold that will prevent IRQL from going to DIRQL, then falling back to
DISPATCH_LEVEL which will then allow your DPC to run where you will
merrily
dump all over the data he/she/it was accessing. What is worse is this
…
you update it and the app then writes over your update. He/she/it will
then
run around mewling and whining about how you missed an interrupt.

Oh … and there was no mention I saw about cache lines getting
royally
hosed.

The best idea is using a asyncrnous IO in a device IOCTL. But App
probably
won;t like that since he/she/it will have some work to do. :slight_smile:

–
Gary G. Little
Have Computer, Will Travel …
909-698-3191
909-551-2105

“John Reilly” wrote in message
> news:xxxxx@ntdev…
> >
> > I have a board that reads radar image data. The radar sweep is
> divided
> > into 2048 sectors. Each time a new sector is ready, the board
> interrupts
> > and my driver DMAs that sector’s data into a buffer provided by the
> > application. It all works.
> >
> > The board has a register containing the number of the sector whose
> data
> > was just DMA’d. My driver provides an IOCTL to read this register.
> All
> > well and good.
> >
> > EXCEPT, the ugly user, who is in my company and thus thinks he can
> > influence the driver design, doesn’t want to poll this register. He
> wants
> > to pass my driver a pointer to a memory location, and wants the
driver
> to
> > write the 4-byte sector number during each DPC for ISR.
> >
> > Who else thinks this is a crummy design? Or a good idea? Is there
> any
> > danger of the app getting a bad value because it reads part of the
> value
> > and the driver updates the other part?
> >
> > Thanks for any ammunition to use against the user!
> > john.
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> You are currently subscribed to ntdev as: michal.vodicka@st.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

—
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

13

Sure, it depends. I guess it is application designer problem, driver is
always the same.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

From: xxxxx@storagecraft.com[SMTP:xxxxx@storagecraft.com]
Reply To: xxxxx@lists.osr.com
Sent: Tuesday, January 21, 2003 11:36 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: Driver Design and Data Integrity

Yes, but it is still in one thread of execution. I guess it depends on
the requirements.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Tuesday, January 21, 2003 2:23 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Driver Design and Data Integrity

Yes but one UM thread is enough. Several overlapped IOCTLs (up to 64)
can be
passed to driver and WaitForMultipleObjects can be used for waiting for
overlapped events. When driver completes an IRP, UM thread processed it,
passes new request to driver and waits again.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

> ----------
> From: xxxxx@storagecraft.com[SMTP:xxxxx@storagecraft.com]
> Reply To: xxxxx@lists.osr.com
> Sent: Tuesday, January 21, 2003 9:09 PM
> To: xxxxx@lists.osr.com
> Subject: [ntdev] Re: Driver Design and Data Integrity
>
>
> I would consider pending multiple overlapped IOCTLs to the driver and
> have UM threads (start with something like 16 threads) to wait on
these
> pended IOCTLs. When the driver has some data, it should fill in a data
> structure (your sector number) and complete one of the pended IOCTLs.
> Since you data is very small, you can send multiple sector numbers in
> one IOCTL. Suppose that you get several sectors of data before you go
> and post the data to the IOCTL and complete it… If you send in a MAX
> count sized buffer on the pended IOCTL, you can send a chunk of
sectors
> numbers in one operation.
>
> You will find that this is a very efficient and manageable mechanism
to
> accomplish your desired task. It is half of your design and half the
> ugly user design.
>
> Jamey
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
> Sent: Tuesday, January 21, 2003 11:45 AM
> To: NT Developers Interest List
> Subject: [ntdev] Re: Driver Design and Data Integrity
>
> Actually, on second thought, rather a dumb idea thought up by a rather
> lazy
> application geek who couldn’t find his/her/its ass if he/she/it were
> sitting
> on it. And you may quote me.
>
> Yes … you writing to it in a DPC will ensure you’re synchronization.
> But
> there is nothing he/she/it can do that will ensure that you can’t
> clobber
> the value while he/she/it is accessing it. There are no “spinlocks”
they
> can
> hold that will prevent IRQL from going to DIRQL, then falling back to
> DISPATCH_LEVEL which will then allow your DPC to run where you will
> merrily
> dump all over the data he/she/it was accessing. What is worse is this
> …
> you update it and the app then writes over your update. He/she/it will
> then
> run around mewling and whining about how you missed an interrupt.
>
> Oh … and there was no mention I saw about cache lines getting
royally
> hosed.
>
> The best idea is using a asyncrnous IO in a device IOCTL. But App
> probably
> won;t like that since he/she/it will have some work to do. :slight_smile:
>
> –
> Gary G. Little
> Have Computer, Will Travel …
> 909-698-3191
> 909-551-2105
>
> “John Reilly” wrote in message
> > news:xxxxx@ntdev…
> > >
> > > I have a board that reads radar image data. The radar sweep is
> > divided
> > > into 2048 sectors. Each time a new sector is ready, the board
> > interrupts
> > > and my driver DMAs that sector’s data into a buffer provided by the
> > > application. It all works.
> > >
> > > The board has a register containing the number of the sector whose
> > data
> > > was just DMA’d. My driver provides an IOCTL to read this register.
> > All
> > > well and good.
> > >
> > > EXCEPT, the ugly user, who is in my company and thus thinks he can
> > > influence the driver design, doesn’t want to poll this register. He
> > wants
> > > to pass my driver a pointer to a memory location, and wants the
> driver
> > to
> > > write the 4-byte sector number during each DPC for ISR.
> > >
> > > Who else thinks this is a crummy design? Or a good idea? Is there
> > any
> > > danger of the app getting a bad value because it reads part of the
> > value
> > > and the driver updates the other part?
> > >
> > > Thanks for any ammunition to use against the user!
> > > john.
> > >
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: michal.vodicka@st.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> You are currently subscribed to ntdev as: michal.vodicka@st.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

14

The driver could accumulate sector count internally to hand it out to the
application on next poll without waiting for interrupt possibly. This would
remove the need to emit several IOCTLs. (Driver would wait for next
interrupt before completing the IRP if no interrupt occured since last
poll.)

An argument *for* ‘polling’ by IOCTLs: UM app has to wait until a specific
sector count is reached anyway. With counter in shared memory it has to
implement this itself by polling the memory location. Using IOCTL the
synchronization is ‘for free’.

----- Original Message -----
From: “Michal Vodicka”
To: “NT Developers Interest List”
Sent: Tuesday, January 21, 2003 11:23 PM
Subject: [ntdev] Re: Driver Design and Data Integrity

> Yes but one UM thread is enough. Several overlapped IOCTLs (up to 64) can
be
> passed to driver and WaitForMultipleObjects can be used for waiting for
> overlapped events. When driver completes an IRP, UM thread processed it,
> passes new request to driver and waits again.
>
> Best regards,
>
> Michal Vodicka
> STMicroelectronics Design and Application s.r.o.
> [michal.vodicka@st.com, http:://www.st.com]
>
> > ----------
> > From: xxxxx@storagecraft.com[SMTP:xxxxx@storagecraft.com]
> > Reply To: xxxxx@lists.osr.com
> > Sent: Tuesday, January 21, 2003 9:09 PM
> > To: xxxxx@lists.osr.com
> > Subject: [ntdev] Re: Driver Design and Data Integrity
> >
> >
> > I would consider pending multiple overlapped IOCTLs to the driver and
> > have UM threads (start with something like 16 threads) to wait on these
> > pended IOCTLs. When the driver has some data, it should fill in a data
> > structure (your sector number) and complete one of the pended IOCTLs.
> > Since you data is very small, you can send multiple sector numbers in
> > one IOCTL. Suppose that you get several sectors of data before you go
> > and post the data to the IOCTL and complete it… If you send in a MAX
> > count sized buffer on the pended IOCTL, you can send a chunk of sectors
> > numbers in one operation.
> >
> > You will find that this is a very efficient and manageable mechanism to
> > accomplish your desired task. It is half of your design and half the
> > ugly user design.
> >
> > Jamey
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
> > Sent: Tuesday, January 21, 2003 11:45 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: Driver Design and Data Integrity
> >
> > Actually, on second thought, rather a dumb idea thought up by a rather
> > lazy
> > application geek who couldn’t find his/her/its ass if he/she/it were
> > sitting
> > on it. And you may quote me.
> >
> > Yes … you writing to it in a DPC will ensure you’re synchronization.
> > But
> > there is nothing he/she/it can do that will ensure that you can’t
> > clobber
> > the value while he/she/it is accessing it. There are no “spinlocks” they
> > can
> > hold that will prevent IRQL from going to DIRQL, then falling back to
> > DISPATCH_LEVEL which will then allow your DPC to run where you will
> > merrily
> > dump all over the data he/she/it was accessing. What is worse is this
> > …
> > you update it and the app then writes over your update. He/she/it will
> > then
> > run around mewling and whining about how you missed an interrupt.
> >
> > Oh … and there was no mention I saw about cache lines getting royally
> > hosed.
> >
> > The best idea is using a asyncrnous IO in a device IOCTL. But App
> > probably
> > won;t like that since he/she/it will have some work to do. :slight_smile:
> >
> > –
> > Gary G. Little
> > Have Computer, Will Travel …
> > 909-698-3191
> > 909-551-2105
> >
> > “John Reilly” wrote in message
> > news:xxxxx@ntdev…
> > >
> > > I have a board that reads radar image data. The radar sweep is
> > divided
> > > into 2048 sectors. Each time a new sector is ready, the board
> > interrupts
> > > and my driver DMAs that sector’s data into a buffer provided by the
> > > application. It all works.
> > >
> > > The board has a register containing the number of the sector whose
> > data
> > > was just DMA’d. My driver provides an IOCTL to read this register.
> > All
> > > well and good.
> > >
> > > EXCEPT, the ugly user, who is in my company and thus thinks he can
> > > influence the driver design, doesn’t want to poll this register. He
> > wants
> > > to pass my driver a pointer to a memory location, and wants the driver
> > to
> > > write the 4-byte sector number during each DPC for ISR.
> > >
> > > Who else thinks this is a crummy design? Or a good idea? Is there
> > any
> > > danger of the app getting a bad value because it reads part of the
> > value
> > > and the driver updates the other part?
> > >
> > > Thanks for any ammunition to use against the user!
> > > john.
> > >
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: michal.vodicka@st.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@epost.de
> To unsubscribe send a blank email to xxxxx@lists.osr.com

15

You can do the same and use several IOCTLS. With multiple threads, you
do not need to serialize data coming from the driver to one thread. Each
IOCTL that completes can contain as much data as it can pull from a
queue in the driver.

Hey, it looks like we are all in the same neighborhood… I am sure he
will find a solution in the past few posts :slight_smile:

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Volker Moebius
Sent: Tuesday, January 21, 2003 2:52 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Driver Design and Data Integrity

The driver could accumulate sector count internally to hand it out to
the
application on next poll without waiting for interrupt possibly. This
would
remove the need to emit several IOCTLs. (Driver would wait for next
interrupt before completing the IRP if no interrupt occured since last
poll.)

An argument *for* ‘polling’ by IOCTLs: UM app has to wait until a
specific
sector count is reached anyway. With counter in shared memory it has to
implement this itself by polling the memory location. Using IOCTL the
synchronization is ‘for free’.

----- Original Message -----
From: “Michal Vodicka”
To: “NT Developers Interest List”
Sent: Tuesday, January 21, 2003 11:23 PM
Subject: [ntdev] Re: Driver Design and Data Integrity

> Yes but one UM thread is enough. Several overlapped IOCTLs (up to 64)
can
be
> passed to driver and WaitForMultipleObjects can be used for waiting
for
> overlapped events. When driver completes an IRP, UM thread processed
it,
> passes new request to driver and waits again.
>
> Best regards,
>
> Michal Vodicka
> STMicroelectronics Design and Application s.r.o.
> [michal.vodicka@st.com, http:://www.st.com]
>
> > ----------
> > From: xxxxx@storagecraft.com[SMTP:xxxxx@storagecraft.com]
> > Reply To: xxxxx@lists.osr.com
> > Sent: Tuesday, January 21, 2003 9:09 PM
> > To: xxxxx@lists.osr.com
> > Subject: [ntdev] Re: Driver Design and Data Integrity
> >
> >
> > I would consider pending multiple overlapped IOCTLs to the driver
and
> > have UM threads (start with something like 16 threads) to wait on
these
> > pended IOCTLs. When the driver has some data, it should fill in a
data
> > structure (your sector number) and complete one of the pended
IOCTLs.
> > Since you data is very small, you can send multiple sector numbers
in
> > one IOCTL. Suppose that you get several sectors of data before you
go
> > and post the data to the IOCTL and complete it… If you send in a
MAX
> > count sized buffer on the pended IOCTL, you can send a chunk of
sectors
> > numbers in one operation.
> >
> > You will find that this is a very efficient and manageable mechanism
to
> > accomplish your desired task. It is half of your design and half the
> > ugly user design.
> >
> > Jamey
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
> > Sent: Tuesday, January 21, 2003 11:45 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: Driver Design and Data Integrity
> >
> > Actually, on second thought, rather a dumb idea thought up by a
rather
> > lazy
> > application geek who couldn’t find his/her/its ass if he/she/it were
> > sitting
> > on it. And you may quote me.
> >
> > Yes … you writing to it in a DPC will ensure you’re
synchronization.
> > But
> > there is nothing he/she/it can do that will ensure that you can’t
> > clobber
> > the value while he/she/it is accessing it. There are no “spinlocks”
they
> > can
> > hold that will prevent IRQL from going to DIRQL, then falling back
to
> > DISPATCH_LEVEL which will then allow your DPC to run where you will
> > merrily
> > dump all over the data he/she/it was accessing. What is worse is
this
> > …
> > you update it and the app then writes over your update. He/she/it
will
> > then
> > run around mewling and whining about how you missed an interrupt.
> >
> > Oh … and there was no mention I saw about cache lines getting
royally
> > hosed.
> >
> > The best idea is using a asyncrnous IO in a device IOCTL. But App
> > probably
> > won;t like that since he/she/it will have some work to do. :slight_smile:
> >
> > –
> > Gary G. Little
> > Have Computer, Will Travel …
> > 909-698-3191
> > 909-551-2105
> >
> > “John Reilly” wrote in message
> > news:xxxxx@ntdev…
> > >
> > > I have a board that reads radar image data. The radar sweep is
> > divided
> > > into 2048 sectors. Each time a new sector is ready, the board
> > interrupts
> > > and my driver DMAs that sector’s data into a buffer provided by
the
> > > application. It all works.
> > >
> > > The board has a register containing the number of the sector whose
> > data
> > > was just DMA’d. My driver provides an IOCTL to read this
register.
> > All
> > > well and good.
> > >
> > > EXCEPT, the ugly user, who is in my company and thus thinks he can
> > > influence the driver design, doesn’t want to poll this register.
He
> > wants
> > > to pass my driver a pointer to a memory location, and wants the
driver
> > to
> > > write the 4-byte sector number during each DPC for ISR.
> > >
> > > Who else thinks this is a crummy design? Or a good idea? Is
there
> > any
> > > danger of the app getting a bad value because it reads part of the
> > value
> > > and the driver updates the other part?
> > >
> > > Thanks for any ammunition to use against the user!
> > > john.
> > >
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: michal.vodicka@st.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@epost.de
> To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

16

Just do the right thing. Consider the perspectives, your customer, your salesman, the administator, the environment your driver is going into. What may be right for a general purpose machine, may be the wrong approach for a dedicated function machine. Try a variety of approaches, polling, polling and waiting, waiting only. See which one works best. Have your driver support them all. Don’t dictate policy in your driver. Defer policy to higher level functions. Let them decide how best to utilize the services that you provide.

Duane.

-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Tuesday, January 21, 2003 6:06 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Driver Design and Data Integrity

You can do the same and use several IOCTLS. With multiple threads, you
do not need to serialize data coming from the driver to one thread. Each
IOCTL that completes can contain as much data as it can pull from a
queue in the driver.

Hey, it looks like we are all in the same neighborhood… I am sure he
will find a solution in the past few posts :slight_smile:

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Volker Moebius
Sent: Tuesday, January 21, 2003 2:52 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Driver Design and Data Integrity

The driver could accumulate sector count internally to hand it out to
the
application on next poll without waiting for interrupt possibly. This
would
remove the need to emit several IOCTLs. (Driver would wait for next
interrupt before completing the IRP if no interrupt occured since last
poll.)

An argument *for* ‘polling’ by IOCTLs: UM app has to wait until a
specific
sector count is reached anyway. With counter in shared memory it has to
implement this itself by polling the memory location. Using IOCTL the
synchronization is ‘for free’.

----- Original Message -----
From: “Michal Vodicka”
To: “NT Developers Interest List”
Sent: Tuesday, January 21, 2003 11:23 PM
Subject: [ntdev] Re: Driver Design and Data Integrity

> Yes but one UM thread is enough. Several overlapped IOCTLs (up to 64)
can
be
> passed to driver and WaitForMultipleObjects can be used for waiting
for
> overlapped events. When driver completes an IRP, UM thread processed
it,
> passes new request to driver and waits again.
>
> Best regards,
>
> Michal Vodicka
> STMicroelectronics Design and Application s.r.o.
> [michal.vodicka@st.com, http:://www.st.com]
>
> > ----------
> > From: xxxxx@storagecraft.com[SMTP:xxxxx@storagecraft.com]
> > Reply To: xxxxx@lists.osr.com
> > Sent: Tuesday, January 21, 2003 9:09 PM
> > To: xxxxx@lists.osr.com
> > Subject: [ntdev] Re: Driver Design and Data Integrity
> >
> >
> > I would consider pending multiple overlapped IOCTLs to the driver
and
> > have UM threads (start with something like 16 threads) to wait on
these
> > pended IOCTLs. When the driver has some data, it should fill in a
data
> > structure (your sector number) and complete one of the pended
IOCTLs.
> > Since you data is very small, you can send multiple sector numbers
in
> > one IOCTL. Suppose that you get several sectors of data before you
go
> > and post the data to the IOCTL and complete it… If you send in a
MAX
> > count sized buffer on the pended IOCTL, you can send a chunk of
sectors
> > numbers in one operation.
> >
> > You will find that this is a very efficient and manageable mechanism
to
> > accomplish your desired task. It is half of your design and half the
> > ugly user design.
> >
> > Jamey
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
> > Sent: Tuesday, January 21, 2003 11:45 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: Driver Design and Data Integrity
> >
> > Actually, on second thought, rather a dumb idea thought up by a
rather
> > lazy
> > application geek who couldn’t find his/her/its ass if he/she/it were
> > sitting
> > on it. And you may quote me.
> >
> > Yes … you writing to it in a DPC will ensure you’re
synchronization.
> > But
> > there is nothing he/she/it can do that will ensure that you can’t
> > clobber
> > the value while he/she/it is accessing it. There are no “spinlocks”
they
> > can
> > hold that will prevent IRQL from going to DIRQL, then falling back
to
> > DISPATCH_LEVEL which will then allow your DPC to run where you will
> > merrily
> > dump all over the data he/she/it was accessing. What is worse is
this
> > …
> > you update it and the app then writes over your update. He/she/it
will
> > then
> > run around mewling and whining about how you missed an interrupt.
> >
> > Oh … and there was no mention I saw about cache lines getting
royally
> > hosed.
> >
> > The best idea is using a asyncrnous IO in a device IOCTL. But App
> > probably
> > won;t like that since he/she/it will have some work to do. :slight_smile:
> >
> > –
> > Gary G. Little
> > Have Computer, Will Travel …
> > 909-698-3191
> > 909-551-2105
> >
> > “John Reilly” wrote in message
> > news:xxxxx@ntdev…
> > >
> > > I have a board that reads radar image data. The radar sweep is
> > divided
> > > into 2048 sectors. Each time a new sector is ready, the board
> > interrupts
> > > and my driver DMAs that sector’s data into a buffer provided by
the
> > > application. It all works.
> > >
> > > The board has a register containing the number of the sector whose
> > data
> > > was just DMA’d. My driver provides an IOCTL to read this
register.
> > All
> > > well and good.
> > >
> > > EXCEPT, the ugly user, who is in my company and thus thinks he can
> > > influence the driver design, doesn’t want to poll this register.
He
> > wants
> > > to pass my driver a pointer to a memory location, and wants the
driver
> > to
> > > write the 4-byte sector number during each DPC for ISR.
> > >
> > > Who else thinks this is a crummy design? Or a good idea? Is
there
> > any
> > > danger of the app getting a bad value because it reads part of the
> > value
> > > and the driver updates the other part?
> > >
> > > Thanks for any ammunition to use against the user!
> > > john.
> > >
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: michal.vodicka@st.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@epost.de
> To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to ntdev as: xxxxx@infiniconsys.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

17

Not that I have anything against the use of IOCTLs, but you might also
consider WMI in this case. WMI gives you the ability to fire an event w/
data to UM. One particularly nice feature of a WMI solution (may not be
relevant in you case) is that your driver only has to fire the event if an
app is listening for it.

-john

18

WMI is not a performance driven interface, as compared to an Irp model
via IOCtls. If you have significant amounts of data to pass to the user
app, WMI will perform horribly.

Pete

Peter Scott
xxxxx@KernelDrivers.com
www.KernelDrivers.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of John Strange
Sent: Wednesday, January 22, 2003 7:18 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Driver Design and Data Integrity

Not that I have anything against the use of IOCTLs, but you might also
consider WMI in this case. WMI gives you the ability to fire an event
w/
data to UM. One particularly nice feature of a WMI solution (may not be
relevant in you case) is that your driver only has to fire the event if
an
app is listening for it.

-john

You are currently subscribed to ntdev as: xxxxx@kerneldrivers.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

19

> Who else thinks this is a crummy design? Or a good idea? Is there
any

If the memory location is in kernel-mode code - then it is OK, but in
user mode this is very problematic, since user memory is pageable, and
DPC cannot access the pageable memory.

Max

20

> of the 4-byte field. If the application cannot manage

this event before the next interrupt occurs, other
proposed schemes won’t do this neither.

No.
The scheme with sending lots of pended overlapped reads will tolerate
this. The DPC will just pick the next IRP and set up a DMA for its
MDL.
The app’s latencies will not cause data loss, they will only cause the
decrement in the rate in which the overlapped read completions are
delivered to the app.

Max