Hello
What is the best way to achieve the following:
Please advise.
–
Elias
The simplest approach is to use IRP completion as the notification
mechanism. User mode supplies one or more pended read IO requests with the
driver, the driver simply completes one of this requests, providing the
required request data, to notify user mode that it needs to process the
request and provide the response data. User mode is responsible for keeping
the driver supplied with read requests. The read IO requests may of course
be IOCTLs rather than Read.
=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of lallous
Sent: Monday, November 28, 2005 5:07 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] kmode talking to user modeHello
What is the best way to achieve the following:
- kmode wants some data
- kmode fills a request (request has a fixed size) and
notifies user mode 3. kmode waits for reply 4. user mode gets
request and processes it 5. user mode finishes and sends the
response (response has a variable size) to kmodePlease advise.
–
Elias
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256You are currently subscribed to ntdev as:
xxxxx@hollistech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com
Create an event in user mode and open it in the kernel. For details on how
best to achieve this check out the OSR article on sharing events
http://www.osronline.com/article.cfm?id=108.
Then let your service or app wait for the event object to be signalled. When
the kernel wants attention, signal the event.
Your service or app can then contact the driver like using DeviceIoControl
and pass the information for the requests and the reply.
Regards,
Daniel Terhell
Resplendence Software Projects Sp
xxxxx@resplendence.com
http://www.resplendence.com
“lallous” wrote in message news:xxxxx@ntdev…
> Hello
>
> What is the best way to achieve the following:
>
> 1. kmode wants some data
> 2. kmode fills a request (request has a fixed size) and notifies user mode
> 3. kmode waits for reply
> 4. user mode gets request and processes it
> 5. user mode finishes and sends the response (response has a variable
> size) to kmode
>
> Please advise.
>
> –
> Elias
>
>
I’ve never understood why the event model was a better solution to the
‘inverted call’ problem than simply feeding the driver with async read
requests and waiting for their completion.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Daniel Terhell
Sent: Monday, November 28, 2005 10:15 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] kmode talking to user mode
Create an event in user mode and open it in the kernel. For details on
how
best to achieve this check out the OSR article on sharing events
http://www.osronline.com/article.cfm?id=108.
Then let your service or app wait for the event object to be signalled.
When
the kernel wants attention, signal the event.
Your service or app can then contact the driver like using
DeviceIoControl
and pass the information for the requests and the reply.
Regards,
Daniel Terhell
Resplendence Software Projects Sp
xxxxx@resplendence.com
http://www.resplendence.com
“lallous” wrote in message news:xxxxx@ntdev…
> Hello
>
> What is the best way to achieve the following:
>
> 1. kmode wants some data
> 2. kmode fills a request (request has a fixed size) and notifies user
mode
> 3. kmode waits for reply
> 4. user mode gets request and processes it
> 5. user mode finishes and sends the response (response has a variable
> size) to kmode
>
> Please advise.
>
> –
> Elias
>
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
It is easier or so it appears. The driver has no work to do to handle
cancel and other problems associated with a process terminating with
outstanding IO requests. The event becomes bad, but no much that it will
cause a blue screen. The process just becomes almost ‘terminated’, but it
appears safer. It also permits support for both 9x & NT without having to
write different code in the application. There is one runtime check that
can solve the ‘who gets the kernel handle’ problem and after that it all
just works with the same code.
“Roddy, Mark” wrote in message news:xxxxx@ntdev…
I’ve never understood why the event model was a better solution to the
‘inverted call’ problem than simply feeding the driver with async read
requests and waiting for their completion.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Daniel Terhell
Sent: Monday, November 28, 2005 10:15 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] kmode talking to user mode
Create an event in user mode and open it in the kernel. For details on
how
best to achieve this check out the OSR article on sharing events
http://www.osronline.com/article.cfm?id=108.
Then let your service or app wait for the event object to be signalled.
When
the kernel wants attention, signal the event.
Your service or app can then contact the driver like using
DeviceIoControl
and pass the information for the requests and the reply.
Regards,
Daniel Terhell
Resplendence Software Projects Sp
xxxxx@resplendence.com
http://www.resplendence.com
“lallous” wrote in message news:xxxxx@ntdev…
> Hello
>
> What is the best way to achieve the following:
>
> 1. kmode wants some data
> 2. kmode fills a request (request has a fixed size) and notifies user
mode
> 3. kmode waits for reply
> 4. user mode gets request and processes it
> 5. user mode finishes and sends the response (response has a variable
> size) to kmode
>
> Please advise.
>
> –
> Elias
>
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
It is really easier when kernel driver just need to inform app about an event and doesn’t need to pass any data to the app. Inverted call model is better when data have to be passed because they can be packed with notification.
As for possible problems, I don’t see any. App creates an event, sends it to the driver via IOCTLs and driver opens the event again. Event object remains valid even if app crashes. Driver doesn’t need to care about it. If it wants, it can remember file object from IOCTL which was used for event and clean event on this file object cleanup (app handle close).
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of David J. Craig[SMTP:xxxxx@yoshimuni.com]
Reply To: Windows System Software Devs Interest List
Sent: Monday, November 28, 2005 9:11 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] kmode talking to user modeIt is easier or so it appears. The driver has no work to do to handle
cancel and other problems associated with a process terminating with
outstanding IO requests. The event becomes bad, but no much that it will
cause a blue screen. The process just becomes almost ‘terminated’, but it
appears safer. It also permits support for both 9x & NT without having to
write different code in the application. There is one runtime check that
can solve the ‘who gets the kernel handle’ problem and after that it all
just works with the same code.“Roddy, Mark” wrote in message news:xxxxx@ntdev…
> I’ve never understood why the event model was a better solution to the
> ‘inverted call’ problem than simply feeding the driver with async read
> requests and waiting for their completion.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Daniel Terhell
> Sent: Monday, November 28, 2005 10:15 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] kmode talking to user mode
>
> Create an event in user mode and open it in the kernel. For details on
> how
> best to achieve this check out the OSR article on sharing events
> http://www.osronline.com/article.cfm?id=108.
>
> Then let your service or app wait for the event object to be signalled.
> When
> the kernel wants attention, signal the event.
> Your service or app can then contact the driver like using
> DeviceIoControl
> and pass the information for the requests and the reply.
>
> Regards,
>
> Daniel Terhell
> Resplendence Software Projects Sp
> xxxxx@resplendence.com
> http://www.resplendence.com
>
>
>
>
>
>
>
> “lallous” wrote in message news:xxxxx@ntdev…
> > Hello
> >
> > What is the best way to achieve the following:
> >
> > 1. kmode wants some data
> > 2. kmode fills a request (request has a fixed size) and notifies user
> mode
> > 3. kmode waits for reply
> > 4. user mode gets request and processes it
> > 5. user mode finishes and sends the response (response has a variable
> > size) to kmode
> >
> > Please advise.
> >
> > –
> > Elias
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@stratus.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@upek.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
The driver presumably has all the infrastructure in place for handling
‘IRPs’ and cancellation thereof, or it is a broken driver to begin with.
The problem stated included sending a request packet to the driver - in
other words the event model is less efficient as the IRP model already
has the request IRP in the driver to begin with while the event model
has to supply one after the event is signaled. I continue to be
unimpressed with the explanations of why the event model is superior,
although the idea that it provides compatibility with windos9x is
intriguing, in that this implies that developers are still providing new
software for that wretched platform 
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David J. Craig
Sent: Monday, November 28, 2005 3:12 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] kmode talking to user mode
It is easier or so it appears. The driver has no work to do to handle
cancel and other problems associated with a process terminating with
outstanding IO requests. The event becomes bad, but no much that it
will
cause a blue screen. The process just becomes almost ‘terminated’, but
it
appears safer. It also permits support for both 9x & NT without having
to
write different code in the application. There is one runtime check
that
can solve the ‘who gets the kernel handle’ problem and after that it all
just works with the same code.
“Roddy, Mark” wrote in message
news:xxxxx@ntdev…
I’ve never understood why the event model was a better solution to the
‘inverted call’ problem than simply feeding the driver with async read
requests and waiting for their completion.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Daniel Terhell
Sent: Monday, November 28, 2005 10:15 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] kmode talking to user mode
Create an event in user mode and open it in the kernel. For details on
how
best to achieve this check out the OSR article on sharing events
http://www.osronline.com/article.cfm?id=108.
Then let your service or app wait for the event object to be signalled.
When
the kernel wants attention, signal the event.
Your service or app can then contact the driver like using
DeviceIoControl
and pass the information for the requests and the reply.
Regards,
Daniel Terhell
Resplendence Software Projects Sp
xxxxx@resplendence.com
http://www.resplendence.com
“lallous” wrote in message news:xxxxx@ntdev…
> Hello
>
> What is the best way to achieve the following:
>
> 1. kmode wants some data
> 2. kmode fills a request (request has a fixed size) and notifies user
mode
> 3. kmode waits for reply
> 4. user mode gets request and processes it
> 5. user mode finishes and sends the response (response has a variable
> size) to kmode
>
> Please advise.
>
> –
> Elias
>
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.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@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
In some driver models such as video miniport, there’s
no way to pend a request, so shared event is the only
option.
Calvin Guan (Windows DDK MVP)
NetXtreme Longhorn Miniport Prime
Broadcom Corp. www.broadcom.com
— “Roddy, Mark” wrote:
> I’ve never understood why the event model was a
> better solution to the
> ‘inverted call’ problem than simply feeding the
> driver with async read
> requests and waiting for their completion.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf
> Of Daniel Terhell
> Sent: Monday, November 28, 2005 10:15 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] kmode talking to user mode
>
> Create an event in user mode and open it in the
> kernel. For details on
> how
> best to achieve this check out the OSR article on
> sharing events
> http://www.osronline.com/article.cfm?id=108.
>
> Then let your service or app wait for the event
> object to be signalled.
> When
> the kernel wants attention, signal the event.
> Your service or app can then contact the driver like
> using
> DeviceIoControl
> and pass the information for the requests and the
> reply.
>
> Regards,
>
> Daniel Terhell
> Resplendence Software Projects Sp
> xxxxx@resplendence.com
> http://www.resplendence.com
>
>
>
>
>
>
>
> “lallous” wrote in message
> news:xxxxx@ntdev…
> > Hello
> >
> > What is the best way to achieve the following:
> >
> > 1. kmode wants some data
> > 2. kmode fills a request (request has a fixed
> size) and notifies user
> mode
> > 3. kmode waits for reply
> > 4. user mode gets request and processes it
> > 5. user mode finishes and sends the response
> (response has a variable
> > size) to kmode
> >
> > Please advise.
> >
> > –
> > Elias
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@stratus.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: unknown
> lmsubst tag argument: ‘’
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
__________________________________________________________
Find your next car at http://autos.yahoo.ca
> Create an event in user mode and open it in the kernel.
Or better - pass the event handle to the driver via some IOCTL, and call
ObReferenceObjectByHandle inside the driver.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
I would think that the event model would be faster since it is only
setting a value in a structure that is shared between user-mode and
kernel and causing the app to wake up. It bypasses the IO manager -
there are no IRPs associated with it once the initial setup has been
done. With the IRP model, the notification has to travel through the IO
manager for each nitification.
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Monday, November 28, 2005 4:01 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] kmode talking to user mode
The driver presumably has all the infrastructure in place for handling
‘IRPs’ and cancellation thereof, or it is a broken driver to begin with.
The problem stated included sending a request packet to the driver - in
other words the event model is less efficient as the IRP model already
has the request IRP in the driver to begin with while the event model
has to supply one after the event is signaled. I continue to be
unimpressed with the explanations of why the event model is superior,
although the idea that it provides compatibility with windos9x is
intriguing, in that this implies that developers are still providing new
software for that wretched platform
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David J. Craig
Sent: Monday, November 28, 2005 3:12 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] kmode talking to user mode
It is easier or so it appears. The driver has no work to do to handle
cancel and other problems associated with a process terminating with
outstanding IO requests. The event becomes bad, but no much that it
will cause a blue screen. The process just becomes almost ‘terminated’,
but it appears safer. It also permits support for both 9x & NT without
having to write different code in the application. There is one runtime
check that can solve the ‘who gets the kernel handle’ problem and after
that it all
just works with the same code.
“Roddy, Mark” wrote in message
news:xxxxx@ntdev…
I’ve never understood why the event model was a better solution to the
‘inverted call’ problem than simply feeding the driver with async read
requests and waiting for their completion.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Daniel Terhell
Sent: Monday, November 28, 2005 10:15 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] kmode talking to user mode
Create an event in user mode and open it in the kernel. For details on
how best to achieve this check out the OSR article on sharing events
http://www.osronline.com/article.cfm?id=108.
Then let your service or app wait for the event object to be signalled.
When
the kernel wants attention, signal the event.
Your service or app can then contact the driver like using
DeviceIoControl and pass the information for the requests and the reply.
Regards,
Daniel Terhell
Resplendence Software Projects Sp
xxxxx@resplendence.com
http://www.resplendence.com
“lallous” wrote in message news:xxxxx@ntdev…
> Hello
>
> What is the best way to achieve the following:
>
> 1. kmode wants some data
> 2. kmode fills a request (request has a fixed size) and notifies user
mode
> 3. kmode waits for reply
> 4. user mode gets request and processes it 5. user mode finishes and
> sends the response (response has a variable
> size) to kmode
>
> Please advise.
>
> –
> Elias
>
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.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@stratus.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: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Roddy, Mark wrote:
The driver presumably has all the infrastructure in place for handling
‘IRPs’ and cancellation thereof, or it is a broken driver to begin with.
Function drivers, yes. Many/most filter drivers, though, just pass the
buck on IO cancellation. Also, if you have a control device you’re using
to handle these requests, very often its much easier to just use
synchronous IOCTLs and not deal with IRP queuing in that device at all.
Ray
The event is to indicate that user mode should ask the driver what it
needs. Not clear how you are achieving *that* with IRPs.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Monday, November 28, 2005 1:01 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] kmode talking to user mode
The driver presumably has all the infrastructure in place for handling
‘IRPs’ and cancellation thereof, or it is a broken driver to begin with.
The problem stated included sending a request packet to the driver - in
other words the event model is less efficient as the IRP model already
has the request IRP in the driver to begin with while the event model
has to supply one after the event is signaled. I continue to be
unimpressed with the explanations of why the event model is superior,
although the idea that it provides compatibility with windos9x is
intriguing, in that this implies that developers are still providing new
software for that wretched platform
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David J. Craig
Sent: Monday, November 28, 2005 3:12 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] kmode talking to user mode
It is easier or so it appears. The driver has no work to do to handle
cancel and other problems associated with a process terminating with
outstanding IO requests. The event becomes bad, but no much that it
will cause a blue screen. The process just becomes almost ‘terminated’,
but it appears safer. It also permits support for both 9x & NT without
having to write different code in the application. There is one runtime
check that can solve the ‘who gets the kernel handle’ problem and after
that it all
just works with the same code.
“Roddy, Mark” wrote in message
news:xxxxx@ntdev…
I’ve never understood why the event model was a better solution to the
‘inverted call’ problem than simply feeding the driver with async read
requests and waiting for their completion.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Daniel Terhell
Sent: Monday, November 28, 2005 10:15 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] kmode talking to user mode
Create an event in user mode and open it in the kernel. For details on
how best to achieve this check out the OSR article on sharing events
http://www.osronline.com/article.cfm?id=108.
Then let your service or app wait for the event object to be signalled.
When
the kernel wants attention, signal the event.
Your service or app can then contact the driver like using
DeviceIoControl and pass the information for the requests and the reply.
Regards,
Daniel Terhell
Resplendence Software Projects Sp
xxxxx@resplendence.com
http://www.resplendence.com
“lallous” wrote in message news:xxxxx@ntdev…
> Hello
>
> What is the best way to achieve the following:
>
> 1. kmode wants some data
> 2. kmode fills a request (request has a fixed size) and notifies user
mode
> 3. kmode waits for reply
> 4. user mode gets request and processes it 5. user mode finishes and
> sends the response (response has a variable
> size) to kmode
>
> Please advise.
>
> –
> Elias
>
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.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@stratus.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: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Not really in my case, but in one instance I specifically implemented events
(unnamed) so that the app would work on both types of Windows. There was
some data required, but the overlapped capability was not permitted on 9x
and this was even before ME came out. Using named events would solve the
problem of the app crashing if the driver attempts to open it each time it
wants to signal the app.
“Roddy, Mark” wrote in message news:xxxxx@ntdev…
The driver presumably has all the infrastructure in place for handling
‘IRPs’ and cancellation thereof, or it is a broken driver to begin with.
The problem stated included sending a request packet to the driver - in
other words the event model is less efficient as the IRP model already
has the request IRP in the driver to begin with while the event model
has to supply one after the event is signaled. I continue to be
unimpressed with the explanations of why the event model is superior,
although the idea that it provides compatibility with windos9x is
intriguing, in that this implies that developers are still providing new
software for that wretched platform
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David J. Craig
Sent: Monday, November 28, 2005 3:12 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] kmode talking to user mode
It is easier or so it appears. The driver has no work to do to handle
cancel and other problems associated with a process terminating with
outstanding IO requests. The event becomes bad, but no much that it
will
cause a blue screen. The process just becomes almost ‘terminated’, but
it
appears safer. It also permits support for both 9x & NT without having
to
write different code in the application. There is one runtime check
that
can solve the ‘who gets the kernel handle’ problem and after that it all
just works with the same code.
“Roddy, Mark” wrote in message
news:xxxxx@ntdev…
I’ve never understood why the event model was a better solution to the
‘inverted call’ problem than simply feeding the driver with async read
requests and waiting for their completion.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Daniel Terhell
Sent: Monday, November 28, 2005 10:15 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] kmode talking to user mode
Create an event in user mode and open it in the kernel. For details on
how
best to achieve this check out the OSR article on sharing events
http://www.osronline.com/article.cfm?id=108.
Then let your service or app wait for the event object to be signalled.
When
the kernel wants attention, signal the event.
Your service or app can then contact the driver like using
DeviceIoControl
and pass the information for the requests and the reply.
Regards,
Daniel Terhell
Resplendence Software Projects Sp
xxxxx@resplendence.com
http://www.resplendence.com
“lallous” wrote in message news:xxxxx@ntdev…
> Hello
>
> What is the best way to achieve the following:
>
> 1. kmode wants some data
> 2. kmode fills a request (request has a fixed size) and notifies user
mode
> 3. kmode waits for reply
> 4. user mode gets request and processes it
> 5. user mode finishes and sends the response (response has a variable
> size) to kmode
>
> Please advise.
>
> –
> Elias
>
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.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@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
“Brown, Beverly” wrote in message news:xxxxx@ntdev…
>> I would think that the event model would be faster since it is only
>> setting a value in a structure that is shared between user-mode and
>> kernel and causing the app to wake up. It bypasses the IO manager -
>> there are no IRPs associated with it once the initial setup has been
>> done. With the IRP model, the notification has to travel through the IO
>> manager for each nitification.
Actually, I wrote a test on this years ago for a customer. Turns out the
kernel-user transition overhead is the killer, and so waiting on an IRP, or
an event made essentially no difference in performance. IIRC the event won
slightly on the no data case, and the IRP won definitely on the data case.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“Satya Das” wrote in message news:xxxxx@ntdev…
>> The event is to indicate that user mode should ask the driver what it
>> needs. Not clear how you are achieving that with IRPs.
No, all the event can do is say something happened. Having an IRP with a
buffer pended in the driver allows “this thing happened, and here is the
data associated with that”.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
That’s trivial to achieve with IRPs. You just send an IRP asking what
the driver needs. When the driver decides that it needs something it
completes the IRP (presumably with the data about what was needed).
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Satya Das
Sent: Monday, November 28, 2005 1:56 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] kmode talking to user mode
The event is to indicate that user mode should ask the driver what it
needs. Not clear how you are achieving *that* with IRPs.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Monday, November 28, 2005 1:01 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] kmode talking to user mode
The driver presumably has all the infrastructure in place for handling
‘IRPs’ and cancellation thereof, or it is a broken driver to begin with.
The problem stated included sending a request packet to the driver - in
other words the event model is less efficient as the IRP model already
has the request IRP in the driver to begin with while the event model
has to supply one after the event is signaled. I continue to be
unimpressed with the explanations of why the event model is superior,
although the idea that it provides compatibility with windos9x is
intriguing, in that this implies that developers are still providing new
software for that wretched platform
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David J. Craig
Sent: Monday, November 28, 2005 3:12 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] kmode talking to user mode
It is easier or so it appears. The driver has no work to do to handle
cancel and other problems associated with a process terminating with
outstanding IO requests. The event becomes bad, but no much that it
will cause a blue screen. The process just becomes almost ‘terminated’,
but it appears safer. It also permits support for both 9x & NT without
having to write different code in the application. There is one runtime
check that can solve the ‘who gets the kernel handle’ problem and after
that it all
just works with the same code.
“Roddy, Mark” wrote in message
news:xxxxx@ntdev…
I’ve never understood why the event model was a better solution to the
‘inverted call’ problem than simply feeding the driver with async read
requests and waiting for their completion.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Daniel Terhell
Sent: Monday, November 28, 2005 10:15 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] kmode talking to user mode
Create an event in user mode and open it in the kernel. For details on
how best to achieve this check out the OSR article on sharing events
http://www.osronline.com/article.cfm?id=108.
Then let your service or app wait for the event object to be signalled.
When
the kernel wants attention, signal the event.
Your service or app can then contact the driver like using
DeviceIoControl and pass the information for the requests and the reply.
Regards,
Daniel Terhell
Resplendence Software Projects Sp
xxxxx@resplendence.com
http://www.resplendence.com
“lallous” wrote in message news:xxxxx@ntdev…
> Hello
>
> What is the best way to achieve the following:
>
> 1. kmode wants some data
> 2. kmode fills a request (request has a fixed size) and notifies user
mode
> 3. kmode waits for reply
> 4. user mode gets request and processes it 5. user mode finishes and
> sends the response (response has a variable
> size) to kmode
>
> Please advise.
>
> –
> Elias
>
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.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@stratus.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: unknown lmsubst tag argument:
‘’
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: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
I don’t think the cost of completing the IRP is that high compared to
the context switch involved in either case to get the sleeping thread
running again.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Monday, November 28, 2005 1:27 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] kmode talking to user mode
I would think that the event model would be faster since it is only
setting a value in a structure that is shared between user-mode and
kernel and causing the app to wake up. It bypasses the IO manager -
there are no IRPs associated with it once the initial setup has been
done. With the IRP model, the notification has to travel through the IO
manager for each nitification.
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Monday, November 28, 2005 4:01 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] kmode talking to user mode
The driver presumably has all the infrastructure in place for handling
‘IRPs’ and cancellation thereof, or it is a broken driver to begin with.
The problem stated included sending a request packet to the driver - in
other words the event model is less efficient as the IRP model already
has the request IRP in the driver to begin with while the event model
has to supply one after the event is signaled. I continue to be
unimpressed with the explanations of why the event model is superior,
although the idea that it provides compatibility with windos9x is
intriguing, in that this implies that developers are still providing new
software for that wretched platform
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David J. Craig
Sent: Monday, November 28, 2005 3:12 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] kmode talking to user mode
It is easier or so it appears. The driver has no work to do to handle
cancel and other problems associated with a process terminating with
outstanding IO requests. The event becomes bad, but no much that it
will cause a blue screen. The process just becomes almost ‘terminated’,
but it appears safer. It also permits support for both 9x & NT without
having to write different code in the application. There is one runtime
check that can solve the ‘who gets the kernel handle’ problem and after
that it all
just works with the same code.
“Roddy, Mark” wrote in message
news:xxxxx@ntdev…
I’ve never understood why the event model was a better solution to the
‘inverted call’ problem than simply feeding the driver with async read
requests and waiting for their completion.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Daniel Terhell
Sent: Monday, November 28, 2005 10:15 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] kmode talking to user mode
Create an event in user mode and open it in the kernel. For details on
how best to achieve this check out the OSR article on sharing events
http://www.osronline.com/article.cfm?id=108.
Then let your service or app wait for the event object to be signalled.
When
the kernel wants attention, signal the event.
Your service or app can then contact the driver like using
DeviceIoControl and pass the information for the requests and the reply.
Regards,
Daniel Terhell
Resplendence Software Projects Sp
xxxxx@resplendence.com
http://www.resplendence.com
“lallous” wrote in message news:xxxxx@ntdev…
> Hello
>
> What is the best way to achieve the following:
>
> 1. kmode wants some data
> 2. kmode fills a request (request has a fixed size) and notifies user
mode
> 3. kmode waits for reply
> 4. user mode gets request and processes it 5. user mode finishes and
> sends the response (response has a variable
> size) to kmode
>
> Please advise.
>
> –
> Elias
>
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.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@stratus.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: unknown lmsubst tag argument:
‘’
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: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Brown, Beverly wrote:
I would think that the event model would be faster since it is only
setting a value in a structure that is shared between user-mode and
kernel and causing the app to wake up. It bypasses the IO manager -
there are no IRPs associated with it once the initial setup has been
done. With the IRP model, the notification has to travel through the IO
manager for each nitification.
If you trace through an IRP completion, you’ll find that it is a
relatively simple operation. I’d wager that the scheduler context
switch time overwhelms any difference in kernel execution between the
two models.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
So there is an IO pending forever which gets completed or cancelled
right ? How would you tell more than one thread about that though ?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Monday, November 28, 2005 2:03 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] kmode talking to user mode
“Satya Das” wrote in message news:xxxxx@ntdev…
>> The event is to indicate that user mode should ask the driver what it
>> needs. Not clear how you are achieving that with IRPs.
No, all the event can do is say something happened. Having an IRP with
a buffer pended in the driver allows “this thing happened, and here is
the data associated with that”.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting Remove StopSpam from
the email to reply
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
“Satya Das” wrote in message news:xxxxx@ntdev…
So there is an IO pending forever which gets completed or cancelled
right ? How would you tell more than one thread about that though ?
How do you know how many threads to tell about the event? If you have data
when is it safe to dispose of it in the event model?
Basically, if you want the pended IRP model for to handle multiple, you can
either have a queue of IRP’s for each process, or have the IRP’s pass in the
event they are interested in, and queue all the IRP’s for a particular event
in a single queue for the action.
Note, every time I’ve encountered the event model, I have been able to
rewrite it to the Inverted Call with less code in both the user and kernel
space.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply