My understanding is that conceptually a lower filter is supposed to be
attached below the device object it is filtering. Example if I write a disk
lower filter, I would be able to get IRPs from the disk driver but I would
need to send SCSI/ATAPI commands down the stack, where as if I write a disk
upper filter, then I will get IRPs from the other upper filters or devices
and would be sending corresponding disk IRPS down to the disk driver.
I hope so far what all I have written is correct.
Now, I think the same concept should hold for a volume filter also. That
is, if I am writing a volume filter it will attach to the volmgr driver as
upper or lower filter.
So a volume upper filter will sit above volmgr, another such driver is the
volsnap driver. So the stack should look like:
myvolupperfilter
volsnap
volmgr
now if I make my driver a lower filter to volume manager, ideally i should
be seeing this:
volsnap
volmgr
myvolumelowerfilter
but what I see (in device tree is)
volsnap
myvolumelowerfilter
volmgr
I am unsure why this is happening. Is this becasue volmgr is itself both a
class driver and also exposes the volumes (FDOs)? Or is it that for a class
driver the term ‘lower filter’ means ‘lowest amongst other filters’? But if
so, the same should be applicable for the disk class also, and I shouldnt
be needing to filter scsi SRBs…
i would appreciate if someone can help me clear my concept here…
“a lower filter is supposed to be
attached below the FDO it is filtering”
Filters are *always* described with reference to an FDO.
In the normal scheme of things, you have a devnode that has an FDO sitting over a PDO. So, if you want to filter between the FDO and PDO – that is, the equivalent of an upper filter of the PDO – you specify that you want to be the lower filter of the FDO.
thanks for the explainations. but then it kind of opens up more questions…
if, for the disk class, one writes a lower filter, then one has to
handle SRBs when transferring IO commands to the lower driver. Which means
that even when the lower filter sits etween teh dosk FDO and PDO, one can
talk to teh actual bus driver. So why would it be different for a filter to
volmgr?
in volmgr, as I mentioned, I would expect to see IOs to the disk device
being a lower filter to volmgr, but that doesnt happen, all I see is IO
from volsnap, going to the volmgr, that doesnt match with waht we see from
point #1. Why so?
Is it possible to give any use case where one would benifit from writing
a lower filter for an FDO, for any device class?
thanks
ap
On Thu, Jan 5, 2012 at 8:09 PM, wrote:
> Hmmm… well, one correction. You wrote: > >
> > When in fact the more correct concept is: > > “a lower filter is supposed to be > attached below the FDO it is filtering” > > Filters are always described with reference to an FDO. > > In the normal scheme of things, you have a devnode that has an FDO sitting > over a PDO. So, if you want to filter between the FDO and PDO – that is, > the equivalent of an upper filter of the PDO – you specify that you want > to be the lower filter of the FDO. > >
Assuming you mean ‘talk to’ as being able to filter the IRPs to the bus
driver, then above statement is not true. Merely by writing a lower disk
filter driver, you can’t filter the IRPs going to the SCSI bus. You get to
access to SRBs because disk class driver converts the higher level IRPs to
block level IRPs (i.e. with SRBs). As a result, a lower filter to disk FDO
can access the SRBs because by definition, lower filter implies filtering
*after* functional driver has done it’s job.
volmgr is the lowest driver in the volume stack. It creates an FDO
(attached to the Root enumerator PDO) and PDOs for all the volume devices.
As Peter already mentioned, filter drivers are in relation to FDOs so no
matter whether you write an upper volume filter or a lower volume filter,
you will be above the volume PDOs. Look at the following windbg output that
shows a volume PDO and the FDO for volmgr.
0: kd> !drvobj volmgr
Driver object (8a7c2eb0) is for:
\Driver\volmgr
Driver Extension List: (id , addr)
8a7c2cb8 \Driver\volmgr 8a7c2d70 VolMgrControl
85d0dab0 \Driver\PnpManager 85d0db68 0000004c
!DevNode 85d0d8f8 :
DeviceInst is “Root\volmgr\0000”
ServiceName is “volmgr”
The disk class is prefect example where one can benefit from writing a
lower or upper filter, depending on what you wish to achieve in the
filtering.
On Sat, Jan 7, 2012 at 9:08 AM, A P wrote:
> Peter, > > thanks for the explainations. but then it kind of opens up more > questions… > > 1. if, for the disk class, one writes a lower filter, then one has to > handle SRBs when transferring IO commands to the lower driver. Which means > that even when the lower filter sits etween teh dosk FDO and PDO, one can > talk to teh actual bus driver. So why would it be different for a filter to > volmgr? > > 2. in volmgr, as I mentioned, I would expect to see IOs to the disk device > being a lower filter to volmgr, but that doesnt happen, all I see is IO > from volsnap, going to the volmgr, that doesnt match with waht we see from > point #1. Why so? > > 3. Is it possible to give any use case where one would benifit from > writing a lower filter for an FDO, for any device class? > > thanks > > ap > > > > On Thu, Jan 5, 2012 at 8:09 PM, wrote: > >> Hmmm… well, one correction. You wrote: >> >>
>> >> When in fact the more correct concept is: >> >> “a lower filter is supposed to be >> attached below the FDO it is filtering” >> >> Filters are always described with reference to an FDO. >> >> In the normal scheme of things, you have a devnode that has an FDO >> sitting over a PDO. So, if you want to filter between the FDO and PDO – >> that is, the equivalent of an upper filter of the PDO – you specify that >> you want to be the lower filter of the FDO. >> >>