Is it possible to write vendor specific protocol WDM/WDF class
in [Device Drivers]
|
Prev: dsfksvcs.sys missing or corrupt
Next: Virtual Printer
From: Murugesan on 9 Sep 2009 02:09 That driver (what you mentioned)which gets loaded on top of enumerated device will be my lower layer driver which does only PCI read/writes or SD read/writes. But this driver will be controlled by some other vendor specific protocol driver which will loaded on top of this driver. This protocol driver will maintain some vendor specific protocol within it and use PCI/SDIO lower layer drivers to accomplish its actions. So I would like to implement this protocol specific driver as class driver and the PCI/SD client driver as mini driver. Is it possible to develop such architecture ? "Doron Holan [MSFT]" wrote: > for either bus (pci or SD), the bus will enumerate a device for your > hardware. you can then load your WDF driver on top of that device and do > whatever you want. > > d > > -- > > This posting is provided "AS IS" with no warranties, and confers no rights. > > > "Murugesan" <Murugesan(a)discussions.microsoft.com> wrote in message > news:78B81115-0327-4F12-AC8D-F36CFE547AA0(a)microsoft.com... > > Hi all, > > > > I need to write a new WDM class driver for a vendor defined protocol & > > mini > > driver for PCI/SDIO interface. Is it possible to write a new class driver > > for > > vendor defined protocol & also a mini-driver to register/interface with > > the > > class driver ? > > > > >
From: Tim Roberts on 10 Sep 2009 01:19 Murugesan <Murugesan(a)discussions.microsoft.com> wrote: > >That driver (what you mentioned)which gets loaded on top of enumerated device > will be my lower layer driver which does only PCI read/writes or SD >read/writes. But this driver will be controlled by some other vendor specific >protocol driver which will loaded on top of this driver. This protocol driver >will maintain some vendor specific protocol within it and use PCI/SDIO lower >layer drivers to accomplish its actions. So I would like to implement this >protocol specific driver as class driver and the PCI/SD client driver as mini >driver. Is it possible to develop such architecture ? I *THINK* you're getting tangled in the terminology here. The PCI bus driver will expose your device ID, which will load your lower layer driver. That can be its own bus, and expose its own child IDs, which will load the "protocol" driver. You can invent whatever communication scheme you want to between those two drivers, like internal ioctls, or exchanging an interface with function pointers. Usually, a "class/miniport" relationship implies a DLL-like coupling with direct coupling. Although that could be done in this case, I think you'd find it unnecessarily complicates things. -- Tim Roberts, timr(a)probo.com Providenza & Boekelheide, Inc.
From: Murugesan on 10 Sep 2009 11:07 Thanks for your comments Tim. If I understand correctly, your idea is to make each layer treat its lower layer as a bus driver. So each layer should think itself as a function driver from its downstream driver point of view similarly it should think itself as a bus driver from its upstream driver point of view. Am I right ? In other words, each layer of driver creates a FDO as a function driver & creates a PDO as a bus driver to load other function drivers on top of it. This is a good idea. But does microsoft has provided any document for implementing our own class drivers( referring to DLL coupling ....). If yes, could you kindly tell me where can I find such docs ? "Tim Roberts" wrote: > Murugesan <Murugesan(a)discussions.microsoft.com> wrote: > > > >That driver (what you mentioned)which gets loaded on top of enumerated device > > will be my lower layer driver which does only PCI read/writes or SD > >read/writes. But this driver will be controlled by some other vendor specific > >protocol driver which will loaded on top of this driver. This protocol driver > >will maintain some vendor specific protocol within it and use PCI/SDIO lower > >layer drivers to accomplish its actions. So I would like to implement this > >protocol specific driver as class driver and the PCI/SD client driver as mini > >driver. Is it possible to develop such architecture ? > > I *THINK* you're getting tangled in the terminology here. The PCI bus > driver will expose your device ID, which will load your lower layer driver. > That can be its own bus, and expose its own child IDs, which will load the > "protocol" driver. You can invent whatever communication scheme you want > to between those two drivers, like internal ioctls, or exchanging an > interface with function pointers. > > Usually, a "class/miniport" relationship implies a DLL-like coupling with > direct coupling. Although that could be done in this case, I think you'd > find it unnecessarily complicates things. > -- > Tim Roberts, timr(a)probo.com > Providenza & Boekelheide, Inc. >
From: Murugesan on 10 Sep 2009 11:45 Which approach would be best suited ? WDM or WDF ? "Murugesan" wrote: > Thanks for your comments Tim. If I understand correctly, your idea is to make > each layer treat its lower layer as a bus driver. So each layer should think > itself as a function driver from its downstream driver point of view > similarly it should think itself as a bus driver from its upstream driver > point of view. Am I right ? > In other words, each layer of driver creates a FDO as a function driver & > creates a PDO as a bus driver to load other function drivers on top of it. > This is a good idea. But does microsoft has provided any document for > implementing our own class drivers( referring to DLL coupling ....). If yes, > could you kindly tell me where can I find such docs ? > > "Tim Roberts" wrote: > > > Murugesan <Murugesan(a)discussions.microsoft.com> wrote: > > > > > >That driver (what you mentioned)which gets loaded on top of enumerated device > > > will be my lower layer driver which does only PCI read/writes or SD > > >read/writes. But this driver will be controlled by some other vendor specific > > >protocol driver which will loaded on top of this driver. This protocol driver > > >will maintain some vendor specific protocol within it and use PCI/SDIO lower > > >layer drivers to accomplish its actions. So I would like to implement this > > >protocol specific driver as class driver and the PCI/SD client driver as mini > > >driver. Is it possible to develop such architecture ? > > > > I *THINK* you're getting tangled in the terminology here. The PCI bus > > driver will expose your device ID, which will load your lower layer driver. > > That can be its own bus, and expose its own child IDs, which will load the > > "protocol" driver. You can invent whatever communication scheme you want > > to between those two drivers, like internal ioctls, or exchanging an > > interface with function pointers. > > > > Usually, a "class/miniport" relationship implies a DLL-like coupling with > > direct coupling. Although that could be done in this case, I think you'd > > find it unnecessarily complicates things. > > -- > > Tim Roberts, timr(a)probo.com > > Providenza & Boekelheide, Inc. > >
From: Tim Roberts on 11 Sep 2009 23:17
Murugesan <Murugesan(a)discussions.microsoft.com> wrote: > >Thanks for your comments Tim. If I understand correctly, your idea is to make >each layer treat its lower layer as a bus driver. So each layer should think >itself as a function driver from its downstream driver point of view >similarly it should think itself as a bus driver from its upstream driver >point of view. Am I right ? Yes, I think so. >In other words, each layer of driver creates a FDO as a function driver & >creates a PDO as a bus driver to load other function drivers on top of it. >This is a good idea. Yes, that's the basic idea. >But does microsoft has provided any document for >implementing our own class drivers( referring to DLL coupling ....). If yes, >could you kindly tell me where can I find such docs ? No, it's exactly like linking to a DLL in user mode. One half gets built as a kernel DLL with an import library, and the other half uses the import library and produces a driver. However, like the user-mode DLL model, it doesn't really make sense if there's only one instance of each. The Microsoft model makes sense because there are hundreds of miniports linking to each port driver. -- Tim Roberts, timr(a)probo.com Providenza & Boekelheide, Inc. |