Hi,
I read that their are three main types of WDM drivers: bus-, filter- & function-drivers. Where in the code of existing WDM drivers can I see what type of driver it is?
Thanks in advance for good answer(s).
You can’t find the sign from code. The difference of them is how you will
use them.
2011/2/22
> Hi,
>
> I read that their are three main types of WDM drivers: bus-, filter- &
> function-drivers. Where in the code of existing WDM drivers can I see what
> type of driver it is?
>
> Thanks in advance for good answer(s).
>
> —
> 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
>
With flags like DO_DIRECT_IO & DO_BUFFERED_IO you can define the way, how data will be exchanged between an application and a driver: Thru “Direct I/O Mode” or “Buffered I/O Mode”.
Therefore I guessed, that their are also flags that define what kind of driver it will be: Function-, filter- or bus-driver.
But this belief seems not to be right.
So what you say is: that their are no such flags. And that the the driver type is defined by the way what the driver really does.
-
Ah, does this mean, that the driver type (filter, function or bus) depends on, which MajorFunctions I register and on what I do in this MajorFunctions?
-
If so ==> can you please give me small simple examples for the three driver types. What are the typical MajorFunctions in these driver types and what do they typical do? Can you please tell me the typical MajorFunctions and their typical jobs for those three driver types.
Thanks in advance for all your helpful and good answers.
>> Ah, does this mean, that the driver type (filter, function or bus)
depends on, which MajorFunctions I register and on what I do in this
MajorFunctions?
No, For every WDM driver, you should register all major functions. Although
most of them you will just make irp pass through.
>2. If so ==> can you please give me small simple examples for the three
driver types. What are the typical MajorFunctions in these driver types and
what do they typical do? Can you please tell me the typical MajorFunctions
and their typical jobs for those three driver types.
You can find all three driver demo from Toaster project in WDK.
2011/2/22
>
> With flags like DO_DIRECT_IO & DO_BUFFERED_IO you can define the way, how
> data will be exchanged between an application and a driver: Thru “Direct I/O
> Mode” or “Buffered I/O Mode”.
>
> Therefore I guessed, that their are also flags that define what kind of
> driver it will be: Function-, filter- or bus-driver.
>
> But this belief seems not to be right.
>
>
>
> So what you say is: that their are no such flags. And that the the driver
> type is defined by the way what the driver really does.
>
> 1. Ah, does this mean, that the driver type (filter, function or bus)
> depends on, which MajorFunctions I register and on what I do in this
> MajorFunctions?
>
> 2. If so ==> can you please give me small simple examples for the three
> driver types. What are the typical MajorFunctions in these driver types and
> what do they typical do? Can you please tell me the typical MajorFunctions
> and their typical jobs for those three driver types.
>
>
>
> Thanks in advance for all your helpful and good answers.
>
>
> —
> 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
>
I agree that there isn’t a simple way to discern. But I’ll go out on a limb and at the risk of having it sawn away from beneath me, and make a few observations:
…if your driver’s .inf or its installer is registering itself as an Upper or Lower filter and doesn’t change properties of the FDO or PDO’s … …then it’s likely a filter driver. Ditto if it’s a KDMF style driver and it’s EvtDeviceAdd function is calling WdfFdoInitSetFilter()… …then it’s likely a filter driver.
…if your driver registers itself, presenting formal interfaces for upper layer drivers to call, and it actually handles whatever bus enumeration is required by those other drivers, including passing up events to those drivers when the devices associated with the particular bus class appear, disappear or etc. then it *might* be a bus driver. I say *might* because this description could equally apply to some port drivers. I’ve seen bus drivers that act more like port drivers and port drivers that skate close to being bus drivers.
That said, the best definition I could find for a bus driver comes from ‘Programming The MicroSoft Windows Driver Model’, 2nd Ed, Walter Oney, pg 30: “It’s responsible for managing the connection between the hardware and the computer.” He goes onto say that “For the purposes of WDM, a bus is anything you can plug a device into, etiher physically or metaphorically”, Ibid -pg 31.
Okay, sharpen your saws… 
On Tue, Feb 22, 2011 at 5:42 AM, 张佩 wrote:
>>> Ah, does this mean, that the driver type (filter, function or bus)
>>> depends on, which MajorFunctions I register and on what I do in this
>>> MajorFunctions?
> No, For every WDM driver, you should register all major functions. Although
> most of them you will just make irp pass through.
>
Actually function drivers generally only need to process a small
subset of the available IRP_MJ_ callbacks, typically:
IRP_MJ_CREATE/IRP_MJ_CLOSE/IRP_MJ_CLEANUP/IRP_MJ_READ/IRP_MJ_WRITE/IRP_MJ_DEVICE_CONTROL/IRP_MJ_PNP/IRP_MJ_POWER
Filter drivers need to support all of the request types processed by
the driver they filter, and that may indeed mean supporting all the
IRP callbacks (and perhaps some of the fastio callbacks as well.)
Bus drivers are just function (or rarely filter) drivers that also
enumerate child devices.
Perhaps here would be a good place to start:
http://msdn.microsoft.com/en-us/library/ff564862.aspx
>>>2. If so ==> can you please give me small simple examples for the three
>>> driver types. What are the typical MajorFunctions in these driver types and
>>> what do they typical do? Can you please tell me the typical MajorFunctions
>>> and their typical jobs for those three driver types.
> You can find all three driver demo from Toaster project in WDK.
>
> 2011/2/22
>>
>> With flags like DO_DIRECT_IO & DO_BUFFERED_IO you can define the way, how
>> data will be exchanged between an application and a driver: Thru “Direct I/O
>> Mode” or “Buffered I/O Mode”.
>>
>> Therefore I guessed, that their are also flags that define what kind of
>> driver it will be: Function-, filter- or bus-driver.
>>
>> But this belief seems not to be right.
>>
>>
>>
>> So what you say is: that their are no such flags. And that the the driver
>> type is defined by the way what the driver really does.
>>
>> 1. Ah, does this mean, that the driver type (filter, function or bus)
>> depends on, which MajorFunctions I register and on what I do in this
>> MajorFunctions?
>>
>> 2. If so ==> can you please give me small simple examples for the three
>> driver types. What are the typical MajorFunctions in these driver types and
>> what do they typical do? Can you please tell me the typical MajorFunctions
>> and their typical jobs for those three driver types.
>>
>>
>>
>> Thanks in advance for all your helpful and good answers.
>>
>>
>> —
>> 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
>
> — 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
Function Driver, Bus Driver, and Filter Driver are “roles” that drivers play in the PnP device stack. A driver can function BOTH as a Function Driver and a Bus Driver as it processes different operations.
For example: The USB Host Controller Driver has a role as a Function Driver in that it understands how to translate O/S generic requests and perform those requests on its device. In other words, it knows how to talk to its hardware and perform operations on that hardware.
The USB Host Controller Driver ALSO has a role as a Bus Driver, in that it understands how to enumerate and communicate with other devices that connect through it to the system.
In terms of this:
I find that to be a sloppy definition.
The operational definitions we at OSR use in our classes and publications are:
A Bus Driver manages a (logical or physical) device that is used to connect other devices (either logical or physical) to the system. It is responsible for identifying, and notifying the system of, the arrival/departure of child devices.
A Function Driver manages the functional (that is, operational) aspect of a device. It’s responsible for translating generic O/S requests and performing those requests in a device specific manner. A Function Driver is usually responsible for managing its device?s power state.
A Filter Driver intercepts requests on route to other devices/drivers. A Filter Driver may modify, track, augment, or re-route those requests.
Peter
OSR
xxxxx@siemens.com wrote:
So what you say is: that their are no such flags. And that the the driver type is defined by the way what the driver really does.
Ah, does this mean, that the driver type (filter, function or bus) depends on, which MajorFunctions I register and on what I do in this MajorFunctions?
If so ==> can you please give me small simple examples for the three driver types. What are the typical MajorFunctions in these driver types and what do they typical do? Can you please tell me the typical MajorFunctions and their typical jobs for those three driver types.
This is a somewhat unusual question. Any introductory text on the WDM
architecture will give you a satisfactory 10,000 foot overview of the
different driver types. Even the Wikipedia page on WDM does an OK job.
98% of the WDM drivers in the world are function drivers. When you
think about your audio driver, or your disk driver, those are function
drivers. Filter drivers are stuck above or below a function driver to
add additional functionality. Bus drivers create new devices, each of
which gets its own function driver.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
But if I’m writing a top-level function driver for an output device, why
would I, for example, register (put in the MajorFunction table) entries for
file-system IRPs, IRP_MJ_READ, etc.? There are 26 IRPs and I care about
IRP_MJ_CREATE, IRP_MJ_CLOSE, IRP_MJ_WRITE and of course IRP_MJ_PNP and
IRP_MJ_POWER. I don’t implement DeviceIoControl or ReadFile. Why would I
even want to pass them through? Of course, the rules for filter drivers are
quite different.
The DO_BUFFERED_IO and DO_DIRECT_IO affect only ReadFile and WriteFile, not
DeviceIoControl, which is set by the METHOD_ field in the IOCTL code.
Drivers are defined by what they do, not what IRPs they process or even,
necessarily, by any mode bits.
joe
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of ??
Sent: Tuesday, February 22, 2011 5:43 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] function-, filter- or bus-driver
> Ah, does this mean, that the driver type (filter, function or bus)
depends on, which MajorFunctions I register and on what I do in this
MajorFunctions?
No, For every WDM driver, you should register all major functions. Although
most of them you will just make irp pass through.
>2. If so ==> can you please give me small simple examples for the three
driver types. What are the typical MajorFunctions in these driver types and
what do they typical do? Can you please tell me the typical MajorFunctions
and their typical jobs for those three driver types.
You can find all three driver demo from Toaster project in WDK.
2011/2/22
With flags like DO_DIRECT_IO & DO_BUFFERED_IO you can define the way, how
data will be exchanged between an application and a driver: Thru “Direct I/O
Mode” or “Buffered I/O Mode”.
Therefore I guessed, that their are also flags that define what kind of
driver it will be: Function-, filter- or bus-driver.
But this belief seems not to be right.
So what you say is: that their are no such flags. And that the the driver
type is defined by the way what the driver really does.
1. Ah, does this mean, that the driver type (filter, function or bus)
depends on, which MajorFunctions I register and on what I do in this
MajorFunctions?
2. If so ==> can you please give me small simple examples for the three
driver types. What are the typical MajorFunctions in these driver types and
what do they typical do? Can you please tell me the typical MajorFunctions
and their typical jobs for those three driver types.
Thanks in advance for all your helpful and good answers.
—
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
— 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
–
This message has been scanned for viruses and
dangerous content by http:</http:> MailScanner, and is
believed to be clean.
Peter Viscarola (OSR) wrote:
I find that to be a sloppy definition.
The operational definitions we at OSR use in our classes and publications are:
…
…
…
[/quote]
Fair enough, Peter - point taken. I’ve also seen bus drivers that have roles as function drivers, and filter drivers that are bus filter drivers, and the list goes on. I think your definitions provide a far better way to distinguish between a bus, function or filter driver.
–mjd