WDM - Multiple interface issues.

Devs,

I’m working on a WDM driver for a four-channel serial card. The four
channels share some common hardware, like DMA engine and interrupt logic.
So while the four channels are logically separate, they interact and can
step on each other at the hardware level.

Since I can’t simple create four separate instances, I have experimented
with how to do this. My first experiment was to simply create four
interfaces using IoRegisterDeviceInterface(). This worked, except that each
instance is fed the same PDO in the dispatch routines and I can’t tell one
instance from another. Plus all instances share the same device extension
and therefore IRP queues, which is not the right way to handle the four
separate channels.

So next I called IoCreateDevice(), too. This gave me separate instances
with separate PDO. This is closer to what I need, except that each instance
gets its own interrupt spinlock, and the AddDevice handler gets called four
times with the same hardware resources.

So then I modified StartDevice to only allocate resources on the first
instance call. I modified the device extension to keep track of the
instance index and a table of device extensions. I changed CreateDevice to
create four devices, inserting a unique index in the device extension of
each one and place a table of four device extensions in each device
extension as well. That way, when any instance needs to access the hardware
or spinlock, it simply looks in the device extension for the first instance,
and uses the resources stored in that instance. For activities that are
unique to each instance, like queuing IRPs, each instance uses its local
resources.

That comes closer to doing what I need. The hang up is
IoAttachDeviceToDeviceStack(). If I don’t insert each instance in the
stack, the driver won’t load. I can’t say exactly why, but my gut feeling
is that inserting the device is the “proper” thing to do anyway.

If I do insert the device in the stack, the topmost driver instance happily
takes all the IRPs passed down and dispatches them itself. Not
unreasonable, once I thought about it. Each instance is looking for exactly
the same IRPs, so the topmost one would have no reason to pass it down the
stack.

So it looks like the next step is to examine the IRP being passed down, or
some other context information, to decide if the current instance should
handle the IRP or if it should be passed down.

But at this point, I have enough hacks in place that I’m starting to
question my approach. Is there a better way to do this? I want to keep
this driver as clean and by-the-rules as possible. I’m starting to get
concerned that I’m heading towards one huge collection of hacks and
work-arounds, rather than the cleanest answer.

Any opinions?

Thanks,

Evan

Evan Hillman
General Standards
435-755-0309


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

> I’m working on a WDM driver for a four-channel serial card. The four

channels share some common hardware, like DMA engine and interrupt logic.
So while the four channels are logically separate, they interact and can
step on each other at the hardware level.

Looks like a bus driver is a solution for this.

Max


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Max,

There have been days when I have seen a bus drive by and thought, “Gosh -
life would be so much simpler if I drove one of those instead of wrote
device drivers. At least then I could explain to my friends what I do for a
living.”

I’ll check into the bus driver architecture and see where that leads
me…thanks!

-Evan

> I’m working on a WDM driver for a four-channel serial card. The four
> channels share some common hardware, like DMA engine and
interrupt logic.
> So while the four channels are logically separate, they interact and can
> step on each other at the hardware level.

Looks like a bus driver is a solution for this.

Max


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com