anton
Wed Sep 13 11:54:49 CDT 2006
Don,
> You are assuming a model that is only used in a few cases, there are lots of
> stacks out there with no mini-ports what so ever in them. I would guess
> that less that 10% of my work in the last 12 years of doing Windows drivers
> has involved a mini-port.
It is understandable that miniport driver is not an absolute must . The
only reason why I mentioned it is because I wanted to mention all kind
of drivers that one may encounter on the standard device stack(apart
from bus driver, of course, so that I did not even mention it), in
order to conclude that the term"driver" in your definition, apparently,
refered to the class driver, rather than to any other type of driver
one may encounter
> The reason the distinction is important is that it can impact operation,
> since if the filter is a device specific filter a lower filter for the
> device will work no matter what the underlying class is, but an upper class
> filter will not work if the class is wrong, and have problems if another
> device you do not want filtered is attached.
I fully agree with the above . The most interesting thing is that the
above statement is fully consistent with my definition of terms
"upper-level" and "lower-level" in respect to filter's position on the
stack, relative to that of a class driver.
Lower-level filters monitor interactions between devices and their
class drivers, while upper-level ones moniror interactions between
class drivers and the system. Therefore, upper-level filter can attach
itself to all devices that are managed by the target class driver, but
if some lowest-level driver on one of the stacks that upper-level
filter monitors creates devices that belong to different classes,
upper-level filter can attach itself only to the one of the target
class. Lower-level filter is exactly the opposite - it can attach
itself to all devices that have been created by the target driver below
(even if the driver below creates devices that belong to different
classes), but if some class driver on one of the stacks that
lower-level filter monitors creates multiple device objects and
attaches them to the lowest-level ones that have been created by
different drivers,
lower-level filter can attach itself only to the device(s), created by
the the target lowest-level driver.
It is understandable that, in order to work this way, lower-level and
upper-level filter drivers have to get loaded respectively before and
after class drivers do, so that they are always respectively below and
above class drivers on their stacks.
Anton Bassov
Don Burn wrote:
> <soviet_bloke@hotmail.com> wrote in message
> news:1158109483.114477.49020@i42g2000cwa.googlegroups.com...
> > Don,
> >
> >> lower filter is a filter below the driver, that modifies actions of the
> >> driver, typically as it heads to the hardware. An upper filter is a
> >> filter
> >> above the driver modifying requests (and the requests results) to the
> >> driver.
> >
> > Assuming a standard port-miniport-class architecture, what is "driver"
> > in your definition???? Apparently, it is not port, because port driver
> > is the one that actually deals with the controller, so that there is no
> > need to modify its actions, although you may want to modify requests
> > (and the requests results) that it receives. Apparently, it is not
> > miniport either, because the very idea of miniport driver is to
> > customize interactions between the class and port drivers, so that it
> > does not really matter if your filter driver is below or above miniport
> > driver - in any case, it will be able to have both functionalities that
> > you have mentioned. Therefore, the only driver that left is class
> > driver, and your driver's functionality depends whether it is above or
> > below the class driver - it cannot have them both
>
> You are assuming a model that is only used in a few cases, there are lots of
> stacks out there with no mini-ports what so ever in them. I would guess
> that less that 10% of my work in the last 12 years of doing Windows drivers
> has involved a mini-port.
>
> The reason the distinction is important is that it can impact operation,
> since if the filter is a device specific filter a lower filter for the
> device will work no matter what the underlying class is, but an upper class
> filter will not work if the class is wrong, and have problems if another
> device you do not want filtered is attached. It is for these reasons there
> are two filter values in the registry "UpperFilters" and "LowerFilters".
>
>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>
http://www.windrvr.com
> Remove StopSpam from the email to reply