Can some help me whats the relation between SRb & IRP.
I mean how IRP is converted to SRB by stream class
driver.
How my filter driver(running on top of stream class
driver) access the data read by mini driver
Any help will be gratefully accepted
Amlan
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
SRB is additional structure attached 1-to-1 to the IRP to make the life
simpler for a miniport. The miniport never sees IRPs, it only sees SRBs.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Amlan Mandal”
To: “Windows System Software Devs Interest List”
Sent: Thursday, September 08, 2005 10:40 AM
Subject: [ntdev] SRB & IRP
> Can some help me whats the relation between SRb & IRP.
> I mean how IRP is converted to SRB by stream class
> driver.
> How my filter driver(running on top of stream class
> driver) access the data read by mini driver
> Any help will be gratefully accepted
> Amlan
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.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@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
I’m not familiar with the stream class driver. I can speak about
ScsiPort.sys and StorPort.sys, port drivers, and about disk.sys, a class
driver.
A ScsiPort or StorPort miniport driver is a driver that is nominally the PDO
driver in a (disk, say) device stack. “Nominally” means that the miniport’s
IRP-handling entry addresses (eg, for Create and for Cleanup; IRP-handling
entry points are kept in the miniport’s driver object) have been taken over
by the port driver (the port driver’s entry points will be found in the
IRP-handling entry points for the miniport); this is done at the miniport’s
invitation when it calls the port driver to initialize. Once initialization
is complete, IRPs flow down the device stack, through disk.sys and usually
to entry points belonging to the port driver. The port driver takes each IRP
and builds an SRB to represent the IRP operation or some aspect of it; then
the port driver calls the miniport, passing the SRB as the main parameter.
In other words, the miniport functions mostly through callbacks, with the
callback parameters supplied in the SRB.
Given this explanation, you will understand that there’s no SRB when an IRP
first reaches your driver, and there might be no SRB left when the IRP is
completed (if your driver has an I/O completion routine).
–
James Antognini
Windows DDK and WDK Support
This posting is provided “AS IS” with no warranties, and confers no rights.
“Amlan Mandal” wrote in message news:xxxxx@ntdev…
> Can some help me whats the relation between SRb & IRP.
> I mean how IRP is converted to SRB by stream class
> driver.
> How my filter driver(running on top of stream class
> driver) access the data read by mini driver
> Any help will be gratefully accepted
> Amlan
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
As it has already been mentioned the device object for your device is owned by the stream class,
which receives all IRPs targeted to your device/driver and processes them on your behalf.
If some of them requires an action from minidriver, it creates an SRB, stuffs it appropriately and
sends to the minidriver.
The content of an SRB depends upon the operation that it describes.
Stream class puts original IRP into one of the fields of created SRB (something like
SRB::OriginalIRP, I don’t remember exactly).
Regarding your second question about filtering KS drivers, it’s been asked multiple times on this
list and the answer is always the same - filtering KS based drivers (which includes stream class)
is not supported.
This means that you can install a filter driver and watch IRPs fly by. Assuming that power and PnP
IRPs are of no interest to you, all KS communication is done via IOCTL of some kind. You can
monitor those, but the problem is that the protocol of communication between ksproxy (user mode
thing that handles streaming devices) and KS in undocumented and as such is subject to change.
You can reverse engneer it, but it can only be done for your own amusement or for lab tool. Please
don’t think about putting something like this into a product.
– Max.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-219396-
xxxxx@lists.osr.com] On Behalf Of Amlan Mandal
Sent: Wednesday, September 07, 2005 11:40 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] SRB & IRPCan some help me whats the relation between SRb & IRP.
I mean how IRP is converted to SRB by stream class
driver.
How my filter driver(running on top of stream class
driver) access the data read by mini driver
Any help will be gratefully accepted
Amlan
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256You are currently subscribed to ntdev as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Depending what type of io its is using IRP will store its read data pointed by Irp->AssociatedIrp.SystemBuffer or Irp->MdlAddress
Read SRB has one field named PKSSTREAM_HEADER DataBufferArray
which I suppose will point to read data
Is it correct…
If it is then my question will IRP pointer & SRB pointer that I mentioned will point to same?
Max Paklin wrote:
As it has already been mentioned the device object for your device is owned by the stream class,
which receives all IRPs targeted to your device/driver and processes them on your behalf.
If some of them requires an action from minidriver, it creates an SRB, stuffs it appropriately and
sends to the minidriver.
The content of an SRB depends upon the operation that it describes.
Stream class puts original IRP into one of the fields of created SRB (something like
SRB::OriginalIRP, I don’t remember exactly).
Regarding your second question about filtering KS drivers, it’s been asked multiple times on this
list and the answer is always the same - filtering KS based drivers (which includes stream class)
is not supported.
This means that you can install a filter driver and watch IRPs fly by. Assuming that power and PnP
IRPs are of no interest to you, all KS communication is done via IOCTL of some kind. You can
monitor those, but the problem is that the protocol of communication between ksproxy (user mode
thing that handles streaming devices) and KS in undocumented and as such is subject to change.
You can reverse engneer it, but it can only be done for your own amusement or for lab tool. Please
don’t think about putting something like this into a product.
– Max.
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:bounce-219396-
> xxxxx@lists.osr.com] On Behalf Of Amlan Mandal
> Sent: Wednesday, September 07, 2005 11:40 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] SRB & IRP
>
> Can some help me whats the relation between SRb & IRP.
> I mean how IRP is converted to SRB by stream class
> driver.
> How my filter driver(running on top of stream class
> driver) access the data read by mini driver
> Any help will be gratefully accepted
> Amlan
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.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@yahoo.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@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
---------------------------------
Yahoo! for Good
Click here to donate to the Hurricane Katrina relief effort.
Amlan Mandal wrote:
Depending what type of io its is using IRP will store its read data
pointed by *Irp->AssociatedIrp.SystemBuffer *or *Irp->MdlAddress*
Read SRB has one field named PKSSTREAM_HEADER DataBufferArray
which I suppose will point to read data
Is it correct…
If it is then my question will IRP pointer & SRB pointer that I
mentioned will point to same?
*//*
Why would you even think about making any assumptions like this? What
does it possibly gain you? The algorithm that maps a user-mode IRP to
an SRB has not been documented. That means even if you are correct
today, it might not be correct tomorrow. Also, if you read the
documentation, you’ll see that DataBufferArray points to a LIST of
KSSTREAM_HEADERs, so there is clearly not a one-to-one relationship to IRPs.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim thank u for ur valuable suggestion…then can u suggest one more solution
I want to write a filter driver which will intercept the data sent by vendor specified driver.
I shld elaborate …
I hav an webcam by logitech.Driver is provided by Logitech. Now I will wrtite my filter driver which will run on top of stream class driver(which runs in conjunction with mini driver) will catch the data in the kernel level.
Can u suggest anything…
Help will be gratefully accepted
Tim Roberts wrote:
Amlan Mandal wrote:
> Depending what type of io its is using IRP will store its read data
> pointed by *Irp->AssociatedIrp.SystemBuffer *or Irp->MdlAddress
> Read SRB has one field named PKSSTREAM_HEADER DataBufferArray
> which I suppose will point to read data
> Is it correct…
> If it is then my question will IRP pointer & SRB pointer that I
> mentioned will point to same?
> //
Why would you even think about making any assumptions like this? What
does it possibly gain you? The algorithm that maps a user-mode IRP to
an SRB has not been documented. That means even if you are correct
today, it might not be correct tomorrow. Also, if you read the
documentation, you’ll see that DataBufferArray points to a LIST of
KSSTREAM_HEADERs, so there is clearly not a one-to-one relationship to IRPs.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Amlan Mandal wrote:
Tim thank u for ur valuable suggestion…then can u suggest one more
solution
I want to write a filter driver which will intercept the data sent by
vendor specified driver.
I shld elaborate …
I hav an webcam by logitech.Driver is provided by Logitech. Now I will
wrtite my filter driver which will run on top of stream class
driver(which runs in conjunction with mini driver) will catch the data
in the *kernel level*.
Can u suggest anything…
Help will be gratefully accepted
Several people have pointed out just this week that what you are
proposing is not a supported scenario.
What are you REALLY trying to do? “Filter a stream driver” is not a
task. That’s the path you think you need to take in order to accomplish
your task. What is the real task? Many streaming filter issues can be
solved by writing DirectShow filters.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim,
My task is to transfer data frm webcam to network directly in KERNEL mode(i.e. without going to usre mode).
Now can I add network card to DirectShow filter graph (with the help of proxy) so That I can achieve my goal?
Help is very much needed
Tim Roberts wrote:
Amlan Mandal wrote:
> Tim thank u for ur valuable suggestion…then can u suggest one more
> solution
> I want to write a filter driver which will intercept the data sent by
> vendor specified driver.
> I shld elaborate …
> I hav an webcam by logitech.Driver is provided by Logitech. Now I will
> wrtite my filter driver which will run on top of stream class
> driver(which runs in conjunction with mini driver) will catch the data
> in the kernel level.
> Can u suggest anything…
> Help will be gratefully accepted
Several people have pointed out just this week that what you are
proposing is not a supported scenario.
What are you REALLY trying to do? “Filter a stream driver” is not a
task. That’s the path you think you need to take in order to accomplish
your task. What is the real task? Many streaming filter issues can be
solved by writing DirectShow filters.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
---------------------------------
Yahoo! for Good
Click here to donate to the Hurricane Katrina relief effort.
Amlan Mandal wrote:
My task is to transfer data frm webcam to network directly in KERNEL
mode(i.e. without going to usre mode).
Several of the experts on this list have argued that such a tactic is
unnecessary. If you wrote your network renderer as a standard user-mode
DirectShow filter, you would incur one user/kernel transition per
frame. That is completely insignificant.
Now can I add network card to DirectShow filter graph (with the help
of proxy) so That I can achieve my goal?
Perhaps there is a terminology confusion here. The word “filter” is
seriously overloaded in kernel programming. Your message made it sound
like you wanted to write a WDM filter, to stick into the driver stack
for an existing capture driver and intercept data. That’s a very bad idea.
However, it would be possible to write an AVStream driver (which is also
called a “filter”, but in the DirectShow sense, not the WDM sense) which
acted as a renderer, and used TDI to transmit your data to a network.
There are no samples to do that, so you’d be doing a lot of invention,
but it should be possible. It would still be smarter to do it as a
user-mode filter.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim thanx for ur reply
Tim Roberts wrote:
Amlan Mandal wrote:
>
> My task is to transfer data frm webcam to network directly in KERNEL
> mode(i.e. without going to usre mode).
Several of the experts on this list have argued that such a tactic is
unnecessary. If you wrote your network renderer as a standard user-mode
DirectShow filter, you would incur one user/kernel transition per
frame. That is completely insignificant.
> Now can I add network card to DirectShow filter graph (with the help
> of proxy) so That I can achieve my goal?
Perhaps there is a terminology confusion here. The word “filter” is
seriously overloaded in kernel programming. Your message made it sound
like you wanted to write a WDM filter, to stick into the driver stack
for an existing capture driver and intercept data. That’s a very bad idea.
However, it would be possible to write an AVStream driver (which is also
called a “filter”, but in the DirectShow sense, not the WDM sense) which
acted as a renderer****,
Then what would be my SOURCE FILTER in Kernel Level (in DirectShow filter graph). The webcam is frm Logitech as well as the driver.I dont hav logitech driver source sode
and used TDI to transmit your data to a network.
There are no samples to do that, so you’d be doing a lot of invention,
but it should be possible. It would still be smarter to do it as a
user-mode filter.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
*/Tim Roberts /* wrote:
> However, it would be possible to write an AVStream driver
> (which is also
> called a “filter”, but in the DirectShow sense, not the WDM sense)
> which
> acted as a renderer****,
>
Amlan Mandal wrote:
> Then what would be my SOURCE FILTER in Kernel Level (in DirectShow
> filter graph). The webcam is frm Logitech as well as the driver.I
> dont hav logitech driver source sode
>
The Logitech web cam would be the source filter, just like it is now.
You had always planned to use that, right?
However, I want to re-re-re-emphasize my strong recommendation that you
build a user-mode network renderer rather than invent one in the
kernel. There is a common belief that kernel-mode code is somehow
faster than user-mode code. It ain’t so.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.