> Don, have you considered using IRP_MJ_PNP/IRP_MN_QUERY_INTERFACE? It’s sort of
a middle ground between using PE/COFF-based dynamic linking and WDM filtering.
Hello Arlie,
Thanks for the suggestion. I think this is what Don Burn also suggested but, given Doron’s previous posting,
A KMDF handle is supposed to be local to a particular instance of a KMDF driver.
Passing handles between 2 difference drivers is not supported either ;). Once
we support export drivers, this restriction will work within that framework
where a handle in one driver will work with a driver which exports functions.
it wouldn’t work; at least not without some behind the scenes jiggery-pokery involving WdfFunctions/DriverGlobals.
Don
No, I meant “why make it KMDF?”, not “why do you want an export driver”.
I can see all sorts of (mostly serviceability) reasons why you might
want one of those.
The question is what is KMDF giving you that a *WDM* export driver
wouldn’t? It’s not like it needs to implement PnP and power stuff,
right? Presumably there’s going to be some driver that *imports*
functions from that export driver, and *that* driver needs to have all
the PnP, etc., infrastructure, so sure… *that* driver should be KMDF,
but why the export driver?
Don Ward wrote:
> Just curious: why do you want to use KMDF for an export
> driver?
It would be a replacement of an existing KMDF filter driver
> What do you think it’s going to give you?
Extra performance.
–
Ray
(If you want to reply to me off list, please remove “spamblock.” from my
email address)