I have two drivers in the same device stack - one a FS (file system) filter driver and other a disk class filter driver. I need to pass/associate some information with an Irp received by FS filter which will be later used by disk filter while processing this irp (or any child irps created off this irp by any intermediate driver). Is their any irp/io_stack_location structure field that can be used for this purpose? Please note that if any intermediate driver spawns off child irps this information needs to be propagated along with each irp. Thanks.
The info you need to associate… the info changes on a PER REQUEST basis or as a function of the open instance?
If on a per request basis, I’m not sure what that would be. File system requests aren’t usually directly coupled with requests to the backing store (unless we’re talking non-cached I/O).
If that latter, the File Object might be a convenient way to do this.
Peter
OSR
The information changes on a per request basis.
And are you and Madhu colleagues or is this the topic of the day?
On Tuesday, February 23, 2010, wrote:
> I have two drivers in the same device stack - one a FS (file system) filter driver and other a disk class filter driver. I need to pass/associate some information with an Irp received by FS filter which will be later used by disk filter while processing this irp (or any child irps created off this irp by any intermediate driver). Is their any irp/io_stack_location structure field that can be used for this purpose? Please note that if any intermediate driver spawns off child irps this information needs to be propagated along with each irp. Thanks.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
–
Mark Roddy
Mark Roddy wrote:
And are you and Madhu colleagues or is this the topic of the day?
Funny how that goes. For a while, everyone was doing mirror drivers.
Then, we had a rush on RAM disks. Maybe next week we’ll swing back
around to proactive feature prevention, so I can annoy people with my
windmill-tilting speeches again.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
So, let’s say, your file system filter gets a read via Fast I/O that will be satisfied by the file system from cache.
Which request, exactly, would you like tagged when it gets sent… somewhere?
My point is either I don’t understand your usage scenario (you’ve yet to explain it) or you don’t understand how file systems work. I’m trying to determine which it is. At this point, I’d say either is equally possible.
Peter
OSR
@Mark - No we are not colleague 
My mistake that I used the similar subject line as other poster which I realized after posting. But our questions are not the same.
@Peter - Here is my understanding: In case of a fast IO I will never tag it. If it gets satisfied by system cache then that request will never reach the disk filter driver. And if it does not get satisfied by cache (page fault) then my FS filter driver will receive an Irp based request to satisfy the original fast IO and I can tag it then.
And Yes I just started learning about file systems so may be I’m totally off the track. Please correct me if I’m wrong. Thanks.
Yes, right. So, you’re pretty much on track… There’ll be a page fault from the cache manager, for a group of sectors that’ll include those that the user requested to read. The original read IRP from the user isn’t likely to be passed through the file system to the volume in this case, through, right?
You don’t just want to know the FILE associated with this request, you really and truly want to know that a specific the paging request is associated with a given, particular, user initiated read?
So, for example, the user reads 100 bytes from a given file… the file system faults in 64K worth of that file. You want to carry context from the user request through all the I/O associated with the Cache Manager reading this data. But, when the user reads the NEXT 100 bytes from that same file, you DON’T see a read (it’s satisfied from cache)… you don’t care about it?
And, again, not on an open instance (file handle) but by the actual initiating request. Hmmmm… I don’t know any way to do that in all cases. Somebody smarter in file systems than me might know.
If that’s what you really want to do… you might consider phrasing your question very specifically and asking on NTFSD.
Or maybe somebody here will have an idea,
Peter
OSR
Isn’t this one of the things that top-level-IRP is used for?
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Tuesday, February 23, 2010 3:21 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] passing information between two drivers in the same stack;
Yes, right. So, you’re pretty much on track… There’ll be a page fault from the cache manager, for a group of sectors that’ll include those that the user requested to read. The original read IRP from the user isn’t likely to be passed through the file system to the volume in this case, through, right?
You don’t just want to know the FILE associated with this request, you really and truly want to know that a specific the paging request is associated with a given, particular, user initiated read?
So, for example, the user reads 100 bytes from a given file… the file system faults in 64K worth of that file. You want to carry context from the user request through all the I/O associated with the Cache Manager reading this data. But, when the user reads the NEXT 100 bytes from that same file, you DON’T see a read (it’s satisfied from cache)… you don’t care about it?
And, again, not on an open instance (file handle) but by the actual initiating request. Hmmmm… I don’t know any way to do that in all cases. Somebody smarter in file systems than me might know.
If that’s what you really want to do… you might consider phrasing your question very specifically and asking on NTFSD.
Or maybe somebody here will have an idea,
Peter
OSR
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> My mistake that I used the similar subject line as other poster which I realized after posting.
But our questions are not the same.
Your biggest mistake is the assumption that your two drivers are in the same stack. In fact, your question
does not make sense in itself, because the only entity in the world who is able to relate a file request to
particular disc sectors is underlying FSD itself…
Anton Bassov
TLI has more to do with re-entrancy and keeping track of which locks are
held. There could be other uses internal to a particular FSD implementation,
though that’s not going to be generally applicable. His main issue as I see
it is that he’s assuming some sort of fixed path between the I/O manager
above the FSD and his upper disk filter.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Peter Wieland” wrote in message
news:xxxxx@ntdev…
> Isn’t this one of the things that top-level-IRP is used for?
>
> -p
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
> Sent: Tuesday, February 23, 2010 3:21 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] passing information between two drivers in the same
> stack;
>
> Yes, right. So, you’re pretty much on track… There’ll be a page fault
> from the cache manager, for a group of sectors that’ll include those that
> the user requested to read. The original read IRP from the user isn’t
> likely to be passed through the file system to the volume in this case,
> through, right?
>
> You don’t just want to know the FILE associated with this request, you
> really and truly want to know that a specific the paging request is
> associated with a given, particular, user initiated read?
>
> So, for example, the user reads 100 bytes from a given file… the file
> system faults in 64K worth of that file. You want to carry context from
> the user request through all the I/O associated with the Cache Manager
> reading this data. But, when the user reads the NEXT 100 bytes from that
> same file, you DON’T see a read (it’s satisfied from cache)… you don’t
> care about it?
>
> And, again, not on an open instance (file handle) but by the actual
> initiating request. Hmmmm… I don’t know any way to do that in all
> cases. Somebody smarter in file systems than me might know.
>
> If that’s what you really want to do… you might consider phrasing your
> question very specifically and asking on NTFSD.
>
> Or maybe somebody here will have an idea,
>
> Peter
> OSR
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>