Hi All,
I don’t see much around about BDA let alone using KMDF to
write a driver. We had great luck with KMDF for our previous PCI
driver, but do I need to stick with straight WDM for BDA?
-J
BDA is a subset of avstream right? If so, you can use KMDF in miniport
mode to manage dma and/or protocol i/o (like usb), but you must use the
avstream/ks abstraction for all top edge i/o like incoming
reads/writes/ioctls as well as power/pnp/wmi.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of zeppelin@io.com
Sent: Monday, June 04, 2007 2:52 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] BDA and KMDF
Hi All,
I don’t see much around about BDA let alone using KMDF to
write a driver. We had great luck with KMDF for our previous PCI
driver, but do I need to stick with straight WDM for BDA?
-J
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
The AVStream driver/minidriver model and KMDF currently have too many conflicts/overlap for this to be workable.
We are working on it, but there’s nothing more I can tell you.
For now, you need to use an AvStream BDA Miniport driver (this is not straight WDM). They are described in the WDK section on BDA drivers (Device and driver technologies/Streaming Media/Design Guide/AvStream/Broadcast Driver Architecture is a good place to start, perhaps).
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of zeppelin@io.com
Sent: Monday, June 04, 2007 2:52 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] BDA and KMDF
Hi All,
I don’t see much around about BDA let alone using KMDF to
write a driver. We had great luck with KMDF for our previous PCI
driver, but do I need to stick with straight WDM for BDA?
-J
zeppelin@io.com wrote:
Hi All,
I don’t see much around about BDA let alone using KMDF to write
a driver. We had great luck with KMDF for our previous PCI driver,
but do I need to stick with straight WDM for BDA?
Yes. AVStream already provides the plug-and-play, power processing, and
IRP dispatching insulation that KMDF offers.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Doron Holan wrote:
BDA is a subset of avstream right?
Right. Actually, I can’t decide whether it is a “superset” or a
“subset”. From a WDM point of view, BDA is identical to AVStream. It’s
the exact same ioctls. BDA just adds a large set of additional standard
property, event, and method sets.
If so, you can use KMDF in miniport mode to manage dma and/or protocol i/o (like usb),
“Miniport mode”? Where can I find out about that? (That term isn’t in
the index of the new WDF book…)
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Doron is correct, of course.
However, AvStream has its own DMA abstraction (through stream pointers, KSMAPINFO, adapter objects, etc) for stream data, so for KMDF you are primarily going to be using IOTARGETs if you need them, and can make use of some of the object management capabilities and such.
Do remember that PIRPs in request and method handlers are NOT WDREQUESTS. If you need to pass stream data, or property/method information to a lower driver, you want to follow the same memory and request handling rules used when passing memory used by one WDFREQUEST to a different one.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, June 04, 2007 2:59 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] BDA and KMDF
BDA is a subset of avstream right? If so, you can use KMDF in miniport
mode to manage dma and/or protocol i/o (like usb), but you must use the
avstream/ks abstraction for all top edge i/o like incoming
reads/writes/ioctls as well as power/pnp/wmi.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of zeppelin@io.com
Sent: Monday, June 04, 2007 2:52 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] BDA and KMDF
Hi All,
I don’t see much around about BDA let alone using KMDF to
write a driver. We had great luck with KMDF for our previous PCI
driver, but do I need to stick with straight WDM for BDA?
-J
Miniport mode is telling KMDF not to take over the driver object’s
dispatch table, e.g. setting the flag WdfDriverInitNoDispatchOverride in
WDF_DRIVER_CONFIG_INIT::DriverInitFlags (see the ndisedge example for
usage).
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Monday, June 04, 2007 3:46 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] BDA and KMDF
Doron Holan wrote:
BDA is a subset of avstream right?
Right. Actually, I can’t decide whether it is a “superset” or a
“subset”. From a WDM point of view, BDA is identical to AVStream. It’s
the exact same ioctls. BDA just adds a large set of additional standard
property, event, and method sets.
If so, you can use KMDF in miniport mode to manage dma and/or protocol
i/o (like usb),
“Miniport mode”? Where can I find out about that? (That term isn’t in
the index of the new WDF book…)
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Thank you all for the information and pointers.
-J
At 12:17 PM 6/4/2007, you wrote:
The AVStream driver/minidriver model and KMDF currently have too
many conflicts/overlap for this to be workable.We are working on it, but there’s nothing more I can tell you.
For now, you need to use an AvStream BDA Miniport driver (this is
not straight WDM). They are described in the WDK section on BDA
drivers (Device and driver technologies/Streaming Media/Design
Guide/AvStream/Broadcast Driver Architecture is a good place to
start, perhaps).-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of zeppelin@io.com
Sent: Monday, June 04, 2007 2:52 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] BDA and KMDFHi All,
I don’t see much around about BDA let alone using KMDF to
write a driver. We had great luck with KMDF for our previous PCI
driver, but do I need to stick with straight WDM for BDA?-J
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Actually, I’m thinking that if you don’t say a pin needs mappings, you can safely use the KMDF DMA abstractions on the stream’s virtual addresses. But:
(1) I don’t know if anyone has tried this approach [OTOH, there’s plenty I don’t know].
(2) One thing I worked on pre-KMDF was DMA in AvStream, and we did some things specifically for high-bandwidth performance there that may not work as well for you in KMDF (would primarily matter if you have 32-bit addressable adapter in a 64-bit machine running a 64-bit OS [change would be avaialbe in WS03 SP1 and up], although I believe that eventually they were going to be migrated to the remaining scenarios as well). Again, I don’t know if there’s any previous use knowledge that can apply to this, and you could well find the KMDF performance for your application completely acceptable.
Don’t know if that helps- people who have worked with or understand both to a deeper level than I have may be able to give you better advice on that subject.
Finally, I offer KS-related advice rather tentatively. I worked on one DMA-related feature, a number of bug fixes, and used a few parts in other drivers (such as the system audio drivers) but that’s not given me enough insight to offer (IMO, anyway) good solid guidance on the subject- I only understand the parts I have worked with or had to understand (and can still remember). It’s a very big and complex architecture…
I guess you could say I know parts of the plumbing, but can’t tell you about the rest of the house…
You can call WdfDriverCreate with an option flag indicating you are a miniport driver, and basically KMDF won’t go near the dispatch tables or allow you to use any of the features related to the top edge of the driver.
There is the WDfDeviceMiniportCreate instead of WDfDeviceCreate-
Described in the WDK (among other places) under the KMDF Design side- “Programming Techniques for framework-based drivers / Using Kernel-Mode Driver framework with Miniport drivers”.
Don’t have the book handy, but I’d bet the latter DDI is in the index and can get you near some relevant subject matter.
Without source I would be terrified to use KMDF in a scenario like this,
just my $0.02. We still don’t get KMDF source right? Where is that battle
by the way, is it a dead issue now?
Bill M.
“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
Actually, I’m thinking that if you don’t say a pin needs mappings, you can
safely use the KMDF DMA abstractions on the stream’s virtual addresses.
But:
(1) I don’t know if anyone has tried this approach [OTOH, there’s plenty I
don’t know].
(2) One thing I worked on pre-KMDF was DMA in AvStream, and we did some
things specifically for high-bandwidth performance there that may not work
as well for you in KMDF (would primarily matter if you have 32-bit
addressable adapter in a 64-bit machine running a 64-bit OS [change would be
avaialbe in WS03 SP1 and up], although I believe that eventually they were
going to be migrated to the remaining scenarios as well). Again, I don’t
know if there’s any previous use knowledge that can apply to this, and you
could well find the KMDF performance for your application completely
acceptable.
Don’t know if that helps- people who have worked with or understand both to
a deeper level than I have may be able to give you better advice on that
subject.
Finally, I offer KS-related advice rather tentatively. I worked on one
DMA-related feature, a number of bug fixes, and used a few parts in other
drivers (such as the system audio drivers) but that’s not given me enough
insight to offer (IMO, anyway) good solid guidance on the subject- I only
understand the parts I have worked with or had to understand (and can still
remember). It’s a very big and complex architecture…
I guess you could say I know parts of the plumbing, but can’t tell you about
the rest of the house…
Why would source be any difference here? the KMDF DMA APIs were
designed from the ground up to be divorced from the rest of KMDF, just
like the USB I/O targets (as well as the normal i/o targets) are. Yes,
there are DMA callbacks that you can register for so that they are
called during device power up/down, but DMA does nothing if they are not
registered or the power state machine does not exist. Internally, the
io targets and DMA use the KMDF miniport device object and not the full
blown device object, so they are naturally limited in what they can do
and what components interfact with these objects.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Thursday, June 07, 2007 5:31 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] BDA and KMDF
Without source I would be terrified to use KMDF in a scenario like this,
just my $0.02. We still don’t get KMDF source right? Where is that
battle
by the way, is it a dead issue now?
Bill M.
“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
Actually, I’m thinking that if you don’t say a pin needs mappings, you
can
safely use the KMDF DMA abstractions on the stream’s virtual addresses.
But:
(1) I don’t know if anyone has tried this approach [OTOH, there’s
plenty I
don’t know].
(2) One thing I worked on pre-KMDF was DMA in AvStream, and we did some
things specifically for high-bandwidth performance there that may not
work
as well for you in KMDF (would primarily matter if you have 32-bit
addressable adapter in a 64-bit machine running a 64-bit OS [change
would be
avaialbe in WS03 SP1 and up], although I believe that eventually they
were
going to be migrated to the remaining scenarios as well). Again, I
don’t
know if there’s any previous use knowledge that can apply to this, and
you
could well find the KMDF performance for your application completely
acceptable.
Don’t know if that helps- people who have worked with or understand both
to
a deeper level than I have may be able to give you better advice on that
subject.
Finally, I offer KS-related advice rather tentatively. I worked on one
DMA-related feature, a number of bug fixes, and used a few parts in
other
drivers (such as the system audio drivers) but that’s not given me
enough
insight to offer (IMO, anyway) good solid guidance on the subject- I
only
understand the parts I have worked with or had to understand (and can
still
remember). It’s a very big and complex architecture…
I guess you could say I know parts of the plumbing, but can’t tell you
about
the rest of the house…
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
I am sure your DMA code is fine…well actually I am not. Rather know for
sure. So, I guess source ain’t gonna happen huh?
Bill M.
“Doron Holan” wrote in message
news:xxxxx@ntdev…
Why would source be any difference here? the KMDF DMA APIs were
designed from the ground up to be divorced from the rest of KMDF, just
like the USB I/O targets (as well as the normal i/o targets) are. Yes,
there are DMA callbacks that you can register for so that they are
called during device power up/down, but DMA does nothing if they are not
registered or the power state machine does not exist. Internally, the
io targets and DMA use the KMDF miniport device object and not the full
blown device object, so they are naturally limited in what they can do
and what components interfact with these objects.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Thursday, June 07, 2007 5:31 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] BDA and KMDF
Without source I would be terrified to use KMDF in a scenario like this,
just my $0.02. We still don’t get KMDF source right? Where is that
battle
by the way, is it a dead issue now?
Bill M.
“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
Actually, I’m thinking that if you don’t say a pin needs mappings, you
can
safely use the KMDF DMA abstractions on the stream’s virtual addresses.
But:
(1) I don’t know if anyone has tried this approach [OTOH, there’s
plenty I
don’t know].
(2) One thing I worked on pre-KMDF was DMA in AvStream, and we did some
things specifically for high-bandwidth performance there that may not
work
as well for you in KMDF (would primarily matter if you have 32-bit
addressable adapter in a 64-bit machine running a 64-bit OS [change
would be
avaialbe in WS03 SP1 and up], although I believe that eventually they
were
going to be migrated to the remaining scenarios as well). Again, I
don’t
know if there’s any previous use knowledge that can apply to this, and
you
could well find the KMDF performance for your application completely
acceptable.
Don’t know if that helps- people who have worked with or understand both
to
a deeper level than I have may be able to give you better advice on that
subject.
Finally, I offer KS-related advice rather tentatively. I worked on one
DMA-related feature, a number of bug fixes, and used a few parts in
other
drivers (such as the system audio drivers) but that’s not given me
enough
insight to offer (IMO, anyway) good solid guidance on the subject- I
only
understand the parts I have worked with or had to understand (and can
still
remember). It’s a very big and complex architecture…
I guess you could say I know parts of the plumbing, but can’t tell you
about
the rest of the house…
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer