Hi,
I’m trying to figure out the architecture of a suite of drivers for a PCI card without much success.
The card in question is a (single-function) PCI card with several BARs.
Incorporated in one of the BARs (along with other resources) is a bank of 16550 UARTS.
The 16550 UARTs are to appear as normal windows COM ports.
Another resource on the card is to have its own driver.
The remaining resources are to be accessible from another driver via IOCTL calls from application space.
The above span/share several BARs, and all share a *single* interrupt!
Here’s what I *think* I need to do:
Write a ‘parent’ functional driver that claims the PCI resources and creates child device objects for (i) serial ports, (ii) the other special resource (iii) the remaining memory space (for IOCTL access).
Somehow convince serial.sys to attach to the serial ports associated with PDO (i)
Write a driver for the special resource (ii)
Write a driver for the IOCTL interface (iii)
[BTW are these ‘upper’ drivers actually filter drivers or not?]
How does this sound?
As for the serial stuff, (if I’m on the right track) any pointers to examples on how to write the INF file that simply directs serial.sys to attach to the ports? I got side-tracked thinking serenum.sys was relevent here but I understand that’s wrong!?! I’m also under the impression that mf.sys is no good to me because it’s not a multi-function PCI device!?! I’m not sure about the requirements for ports vs serial etc? I understand someone on this forum did this recenty?
FWIW My initial priority is to get the serial ports going, which I’m assuming involves the ‘parent’ driver and a couple of .INF files?
TIA
Regards,
Mark
If you are sharing the interrupt across the UARTs, serial.sys is not the answer for your device. It does not have logic to share the interrupt across multiple devices. In theory you can use mf.sys to break the device apart into separate functions, but again, the shared interrupt will get you. What you could do is
- write a bus driver
- it enumerates all the COM ports as child stacks with no resources assigned to each PDO
- you load your custom serial driver on top of each PDO. there is a private interface that you can query for from the serial driver which gives you the assigned resources. the FDO handles the shared interrupt logic on behalf of each PDO, notifying each when they have an interrupt.
- the bus driver FDO can expose the custom IOCTL interface or you could enumerate another child stack for the interface, it’s your choice.
d
xxxxx@Microsoft.com wrote:
What you could do is 1) write a bus driver
OK, so this is similar to Walt Oney’s “MULFUNC” sample - a bus driver is
simply a driver that responds to QUERY_DEVICE_RELATIONS-type PnP IRPs
and maintains a collection of PDOs - yes?
- it enumerates all the COM ports as child stacks with no resources
assigned to each PDO 3) you load your custom serial driver on top of
each PDO. there is a private interface that you can query for from
the serial driver which gives you the assigned resources. the FDO
handles the shared interrupt logic on behalf of each PDO, notifying
each when they have an interrupt.
This ‘custom serial driver’ could be a (slightly) modified SERIAL.SYS,
with changes to handle the custom interface, shared interrupt - yes?
- the bus driver FDO can expose
the custom IOCTL interface or you could enumerate another child stack
for the interface, it’s your choice.
OK…
Thanks for your assistance. It’s becoming clearer. On the very rare
occasion that I need to write a windows device driver, I find the most
difficult and frustrating part is working out what type of driver(s) I
need and how they fit into the driver framework! Unfortunately, the very
few drivers I have worked on are very different (and have spanned about
10 years of windows architecture!)
Regards,
–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>
Yes, a bus driver reports PDOs via QDR/BusRelations. If you need to write a bus driver, write it using KMDF. It will abstract all of this away from you and let you focus in on what you need to accomplish vs learning and maintaining some hairy WDM code (bus driver rules are way more complicated then a std FDO).
Yes, the custom serial driver can be derived from serial.sys. Again, there is a KMDF version of serial.sys which should simplify your life quite a bit. You can keep nearly the entire driver intact, the only change would be the enabling/disabling of the interrupt and synchronizing against it.
d
xxxxx@Microsoft.com wrote:
Yes, a bus driver reports PDOs via QDR/BusRelations. If you need to
write a bus driver, write it using KMDF. It will abstract all of
this away from you and let you focus in on what you need to
accomplish vs learning and maintaining some hairy WDM code (bus
driver rules are way more complicated then a std FDO).
Yes, the custom serial driver can be derived from serial.sys. Again,
there is a KMDF version of serial.sys which should simplify your life
quite a bit. You can keep nearly the entire driver intact, the only
change would be the enabling/disabling of the interrupt and
synchronizing against it.
Thanks for pointing me in the right direction Doron. Now to convince
others that me ramping up on KMDF is the right way forward!
Regards,
–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>