KMDF Common Buffer DMA

Tim_Roberts · June 8, 2006, 4:56pm

Let’s say I’m doing a KMDF driver for a non-scatter/gather device for
which the most convenient model is common buffer DMA. (Note how
carefully I worded that to avoid implying that I HAD to use common
buffer DMA…) There are no samples of exactly this scenario, and the
documentation is a bit terse, so I’m guessing a bit on this.

It looks to me like I should create a WDFDMAENABLER, and register
EvtDmaEnablerFill and EvtDmaEnablerFlush handlers. The Fill handler
could then call WdfDmaEnablerWdmGetDmaAdapter, and use that adapter to
call AllocateCommonBuffer, and similarly call FreeCommonBuffer in the
Flush handler. I might also use EvtDmaEnablerDisable to turn off the
device’s DMA pump, if it was still on. But beyond that, I won’t ever
use the DmaEnabler object.

Is that correct?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Doron_Holan · June 8, 2006, 5:14pm

You can use WdfCommonBufferCreate to create common buffers as well.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, June 08, 2006 1:56 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF Common Buffer DMA

Let’s say I’m doing a KMDF driver for a non-scatter/gather device for
which the most convenient model is common buffer DMA. (Note how
carefully I worded that to avoid implying that I HAD to use common
buffer DMA…) There are no samples of exactly this scenario, and the
documentation is a bit terse, so I’m guessing a bit on this.

It looks to me like I should create a WDFDMAENABLER, and register
EvtDmaEnablerFill and EvtDmaEnablerFlush handlers. The Fill handler
could then call WdfDmaEnablerWdmGetDmaAdapter, and use that adapter to
call AllocateCommonBuffer, and similarly call FreeCommonBuffer in the
Flush handler. I might also use EvtDmaEnablerDisable to turn off the
device’s DMA pump, if it was still on. But beyond that, I won’t ever
use the DmaEnabler object.

Is that correct?

–
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

Gary_Little-2 · June 8, 2006, 5:18pm

Nothing requires you to use DMA via WDF. Phil and I found it easier to use
WDM DMA in the driver(s) for which we are responsible.

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@probo.com
Sent: Thursday, June 08, 2006 3:56 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF Common Buffer DMA

Let’s say I’m doing a KMDF driver for a non-scatter/gather device for
which the most convenient model is common buffer DMA. (Note how
carefully I worded that to avoid implying that I HAD to use common
buffer DMA…) There are no samples of exactly this scenario, and the
documentation is a bit terse, so I’m guessing a bit on this.

It looks to me like I should create a WDFDMAENABLER, and register
EvtDmaEnablerFill and EvtDmaEnablerFlush handlers. The Fill handler
could then call WdfDmaEnablerWdmGetDmaAdapter, and use that adapter to
call AllocateCommonBuffer, and similarly call FreeCommonBuffer in the
Flush handler. I might also use EvtDmaEnablerDisable to turn off the
device’s DMA pump, if it was still on. But beyond that, I won’t ever
use the DmaEnabler object.

Is that correct?

–
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

Tim_Roberts · June 8, 2006, 5:32pm

Doron Holan wrote:

You can use WdfCommonBufferCreate to create common buffers as well.

I’ll be darned! I missed that completely. I’m getting used to thinking
about the Wdm services in terms of broad categories, so I was poring
through WdmDmaEnablerXxxx…

Thanks for the hint.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Doron_Holan · June 8, 2006, 5:46pm

There is also WDFDMATRANSACTION in case you missed that.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, June 08, 2006 2:32 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] KMDF Common Buffer DMA

Doron Holan wrote:

You can use WdfCommonBufferCreate to create common buffers as well.

I’ll be darned! I missed that completely. I’m getting used to thinking
about the Wdm services in terms of broad categories, so I was poring
through WdmDmaEnablerXxxx…

Thanks for the hint.

–
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

OSR_Community_User · June 8, 2006, 6:36pm

I’ll add that it was “easier” because we needed arbitrarily large input
and output buffers in a single IOCTL, so we used the “unsafe” method of
embedding buffer pointers in a METHOD_BUFFERED control block, and probing
and locking those buffers so we could DMA into and out of them. It’s a
test harness, and it’s never going to be released into the wild, etc…
“Don’t try this at home, we’re what you call professionals.” Bonus points
to the first one who identifies that reference, and why I might think that
their claim to professionalism is as reliable as my own.

If Microsoft had allowed METHOD_OUT_DIRECT to return a modified input
buffer, we wouldn’t have done all that, we would have defined a
METHOD_IN_DIRECT IOCTL that moved a small amount of data to the hardware,
and brought back a lot of data from it, and a METHOD_OUT_DIRECT IOCTL that
moved a lot of data to the hardware, and moved a small amount of data
back. We were unable to make that particular scenario work, so we gave up
on it and went with the embedded pointer thing.

Even with that, if we weren’t using pre-allocated SGL buffers, I’m not
sure I would dive out of WDF to do WDM-style DMA on the aforementioned
locked buffers. But we are pre-allocating our SGLs, so we have to dive
into WDM so we can use BuildScatterGatherList. Currently that, and
ExFreePoolWithTag, is the only thing keeping us from using this thing on
Windows 2000. I only mention that because if we dropped the pre-allocated
SGLs, we could go with an almost pure KMDF implementation.

If anyone knows how to return more than a status code to the application
sending a METHOD_OUT_DIRECT IOCTL, without resorting to manually
scribbling on the output buffer after the data is transferred to the
hardware, I’d really like to hear about it.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G Little
Sent: Thursday, June 08, 2006 3:18 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF Common Buffer DMA

Nothing requires you to use DMA via WDF. Phil and I found it easier to use
WDM DMA in the driver(s) for which we are responsible.

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@probo.com
Sent: Thursday, June 08, 2006 3:56 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF Common Buffer DMA

Let’s say I’m doing a KMDF driver for a non-scatter/gather device for
which the most convenient model is common buffer DMA. (Note how
carefully I worded that to avoid implying that I HAD to use common
buffer DMA…) There are no samples of exactly this scenario, and the
documentation is a bit terse, so I’m guessing a bit on this.

It looks to me like I should create a WDFDMAENABLER, and register
EvtDmaEnablerFill and EvtDmaEnablerFlush handlers. The Fill handler
could then call WdfDmaEnablerWdmGetDmaAdapter, and use that adapter to
call AllocateCommonBuffer, and similarly call FreeCommonBuffer in the
Flush handler. I might also use EvtDmaEnablerDisable to turn off the
device’s DMA pump, if it was still on. But beyond that, I won’t ever
use the DmaEnabler object.

Is that correct?

–
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

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

Gary_Little-2 · June 9, 2006, 9:38am

Sheesh Phil … there are, after all better programming on Discovery than
MythBusters …

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Philip D Barila
Sent: Thursday, June 08, 2006 5:31 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF Common Buffer DMA

I’ll add that it was “easier” because we needed arbitrarily large input
and output buffers in a single IOCTL, so we used the “unsafe” method of
embedding buffer pointers in a METHOD_BUFFERED control block, and probing
and locking those buffers so we could DMA into and out of them. It’s a
test harness, and it’s never going to be released into the wild, etc…
“Don’t try this at home, we’re what you call professionals.” Bonus points
to the first one who identifies that reference, and why I might think that
their claim to professionalism is as reliable as my own.

If Microsoft had allowed METHOD_OUT_DIRECT to return a modified input
buffer, we wouldn’t have done all that, we would have defined a
METHOD_IN_DIRECT IOCTL that moved a small amount of data to the hardware,
and brought back a lot of data from it, and a METHOD_OUT_DIRECT IOCTL that
moved a lot of data to the hardware, and moved a small amount of data
back. We were unable to make that particular scenario work, so we gave up
on it and went with the embedded pointer thing.

Even with that, if we weren’t using pre-allocated SGL buffers, I’m not
sure I would dive out of WDF to do WDM-style DMA on the aforementioned
locked buffers. But we are pre-allocating our SGLs, so we have to dive
into WDM so we can use BuildScatterGatherList. Currently that, and
ExFreePoolWithTag, is the only thing keeping us from using this thing on
Windows 2000. I only mention that because if we dropped the pre-allocated
SGLs, we could go with an almost pure KMDF implementation.

If anyone knows how to return more than a status code to the application
sending a METHOD_OUT_DIRECT IOCTL, without resorting to manually
scribbling on the output buffer after the data is transferred to the
hardware, I’d really like to hear about it.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G Little
Sent: Thursday, June 08, 2006 3:18 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF Common Buffer DMA

Nothing requires you to use DMA via WDF. Phil and I found it easier to use
WDM DMA in the driver(s) for which we are responsible.

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@probo.com
Sent: Thursday, June 08, 2006 3:56 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF Common Buffer DMA

Let’s say I’m doing a KMDF driver for a non-scatter/gather device for
which the most convenient model is common buffer DMA. (Note how
carefully I worded that to avoid implying that I HAD to use common
buffer DMA…) There are no samples of exactly this scenario, and the
documentation is a bit terse, so I’m guessing a bit on this.

It looks to me like I should create a WDFDMAENABLER, and register
EvtDmaEnablerFill and EvtDmaEnablerFlush handlers. The Fill handler
could then call WdfDmaEnablerWdmGetDmaAdapter, and use that adapter to
call AllocateCommonBuffer, and similarly call FreeCommonBuffer in the
Flush handler. I might also use EvtDmaEnablerDisable to turn off the
device’s DMA pump, if it was still on. But beyond that, I won’t ever
use the DmaEnabler object.

Is that correct?

–
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

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

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

Peter_Viscarola_OSR · June 9, 2006, 10:09am

Recognizing that this is no longer about the topic that started this thread…

I guess the obvious question is: Why not have the OUT buffer contain a data structure – perhaps with the offset/length within the OUT buffer of the data you want sent TO the hardware and the offset/length within the OUT buffer of a place to return data FROM the hardware? While not an immediately obvious design, we’ve found it works quite well…

Or so you consider that “manually scribbling on the output buffer”??

Peter
OSR

OSR_Community_User · June 9, 2006, 12:14pm

Sadly there isn’t without using METHOD_NEITHER or otherwise poking into
user-mode directly. This is the failing of METHOD_DIRECT_*. They’re
great ways to do command+one-way-data but they can’t do bi-directional
data and they can’t return complex status.

If we had a way to do command + bi-directional data + status in a single
I/O control without resulting to METHOD_NEITHER then we could get rid of
a lot of embedded pointers.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Thursday, June 08, 2006 3:31 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF Common Buffer DMA

…

If anyone knows how to return more than a status code to the application
sending a METHOD_OUT_DIRECT IOCTL, without resorting to manually
scribbling on the output buffer after the data is transferred to the
hardware, I’d really like to hear about it.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G Little
Sent: Thursday, June 08, 2006 3:18 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF Common Buffer DMA

Nothing requires you to use DMA via WDF. Phil and I found it easier to
use WDM DMA in the driver(s) for which we are responsible.

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@probo.com
Sent: Thursday, June 08, 2006 3:56 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF Common Buffer DMA

Let’s say I’m doing a KMDF driver for a non-scatter/gather device for
which the most convenient model is common buffer DMA. (Note how
carefully I worded that to avoid implying that I HAD to use common
buffer DMA…) There are no samples of exactly this scenario, and the
documentation is a bit terse, so I’m guessing a bit on this.

It looks to me like I should create a WDFDMAENABLER, and register
EvtDmaEnablerFill and EvtDmaEnablerFlush handlers. The Fill handler
could then call WdfDmaEnablerWdmGetDmaAdapter, and use that adapter to
call AllocateCommonBuffer, and similarly call FreeCommonBuffer in the
Flush handler. I might also use EvtDmaEnablerDisable to turn off the
device’s DMA pump, if it was still on. But beyond that, I won’t ever
use the DmaEnabler object.

Is that correct?

–
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

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

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

OSR_Community_User · June 9, 2006, 12:16pm

Yes, I do consider that “manually scribbling on the output buffer”. If I
have to resort to that kind of inconsistency between the IN and OUT, I
might as well just do it the hard way. Although there is some additional
work to do when you write it, it’s clear what’s happening, and there is no
confusion about in and out buffers. Sure, *I* know why the OUT buffer is
also the IN buffer on this IOCTL, and not that one, but it’s a lot less
clear to the poor intern who follows me.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Friday, June 09, 2006 8:11 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KMDF Common Buffer DMA

Recognizing that this is no longer about the topic that started this
thread…

I guess the obvious question is: Why not have the OUT buffer contain a
data structure – perhaps with the offset/length within the OUT buffer of
the data you want sent TO the hardware and the offset/length within the
OUT buffer of a place to return data FROM the hardware? While not an
immediately obvious design, we’ve found it works quite well…

Or so you consider that “manually scribbling on the output buffer”??

Peter
OSR

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

OSR_Community_User · June 9, 2006, 12:23pm

You could always explain it in a comment so the next person will also
know why.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, June 09, 2006 12:15 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF Common Buffer DMA

Yes, I do consider that “manually scribbling on the output buffer”. If
I have to resort to that kind of inconsistency between the IN and OUT, I
might as well just do it the hard way. Although there is some
additional work to do when you write it, it’s clear what’s happening,
and there is no confusion about in and out buffers. Sure, *I* know why
the OUT buffer is also the IN buffer on this IOCTL, and not that one,
but it’s a lot less clear to the poor intern who follows me.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Friday, June 09, 2006 8:11 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KMDF Common Buffer DMA

Recognizing that this is no longer about the topic that started this
thread…

[quote]
If anyone knows how to return more than a status code to the application
sending a METHOD_OUT_DIRECT IOCTL, without resorting to manually
scribbling on the output buffer after the data is transferred to the
hardware, I’d really like to hear about it [/quote]

I guess the obvious question is: Why not have the OUT buffer contain a
data structure – perhaps with the offset/length within the OUT buffer
of the data you want sent TO the hardware and the offset/length within
the OUT buffer of a place to return data FROM the hardware? While not
an immediately obvious design, we’ve found it works quite well…

Or so you consider that “manually scribbling on the output buffer”??

Peter
OSR

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

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

Peter_Viscarola_OSR · June 9, 2006, 12:25pm

Sorry, Peter, but (at least for the archives) have to I disagree. METHOD_OUT_DIRECT is *absolutely* appropriate for bi-directional data. In Windows, Write access always implies Read access.

Now, whether this is sufficiently clear for the purposes of maintenance (as Phil commented) is a reasonable question. But Windows does indeed allow bi-directional data exchange via IOCTLs without resorting to METHOD_NEITHER.

Peter
OSR

OSR_Community_User · June 9, 2006, 1:21pm

Call me na?ve, but it doesn’t seem like it would be a gigantic IoManager
change to copy the contents of the input buffer back into user-mode on a
METHOD_OUT_DIRECT. Or both METHOD_*_DIRECT, for that matter. But the one
that is killer is METHOD_OUT_DIRECT, because you only get a status value
unless you use the caller’s buffer, which has it’s own issues I’m
addressing in another post.

How about it, Peter W or Doron, is that a reasonable change request to at
least put in the queue to scope?

As you say, Peter W, if you could do that, you could do away with a lot of
embedded pointers. So could I.

Personally, I’d love the idea of a IOCTL_SCSI_PASS_THROUGH_IN/OUT_DIRECT
which had no embedded pointers.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Friday, June 09, 2006 10:13 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF Common Buffer DMA

Sadly there isn’t without using METHOD_NEITHER or otherwise poking into
user-mode directly. This is the failing of METHOD_DIRECT_*. They’re
great ways to do command+one-way-data but they can’t do bi-directional
data and they can’t return complex status.

If we had a way to do command + bi-directional data + status in a single
I/O control without resulting to METHOD_NEITHER then we could get rid of
a lot of embedded pointers.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Thursday, June 08, 2006 3:31 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF Common Buffer DMA

…

If anyone knows how to return more than a status code to the application
sending a METHOD_OUT_DIRECT IOCTL, without resorting to manually
scribbling on the output buffer after the data is transferred to the
hardware, I’d really like to hear about it.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

Tim_Roberts · June 9, 2006, 1:26pm

Brown, Beverly wrote:

You could always explain it in a comment so the next person will also
know why.

Comments? I’m supposed to put comments in my code?

I’ve always ascribed to the theory that “if it was hard to write, it
should be hard to read.”

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

OSR_Community_User · June 9, 2006, 1:34pm

Remember that one of the reasons for doing it with embedded pointers or
METHOD_IN/OUT_DIRECT in the first place is to avoid copies on arbitrarily
large caller buffers. If I have to prepend or append data (what if the
caller expects his data to be there when it’s done? It’s pretty nasty to
tell the user not to assume anything about the contents of a buffer that
should be read only, as far as the API is concerned), then it gets really
ugly.

Either you have to provide an allocator to give the caller a buffer with
pre-allocated space for your status block (prepended, or appended, makes
no difference, you still have to pad the allocation at one end or the
other), or you have to copy the user’s content from the status block space
and then replace it when you are done.

PeterGV, this seems to be your preferred way of doing things, is there a
simplifying [something] I’m missing?

Did I mention that we are being compared for speed to some DOS/RTOS based
tools that don’t have issues like this, so we are mightily constrained
from anything that even looks like it’s a performance penalty. As in: we
profiled to see which copies of things (which just had to be copied) were
more efficient with a memcpy and which ones are more efficient with a
structure assignment, and used the best case selectively for each
structure. And we’re still changing things to minimize and/or eliminate
even those object copies if it’s possible to do so.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Friday, June 09, 2006 10:23 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF Common Buffer DMA

You could always explain it in a comment so the next person will also
know why.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, June 09, 2006 12:15 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF Common Buffer DMA

Yes, I do consider that “manually scribbling on the output buffer”. If
I have to resort to that kind of inconsistency between the IN and OUT, I
might as well just do it the hard way. Although there is some
additional work to do when you write it, it’s clear what’s happening,
and there is no confusion about in and out buffers. Sure, *I* know why
the OUT buffer is also the IN buffer on this IOCTL, and not that one,
but it’s a lot less clear to the poor intern who follows me.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Friday, June 09, 2006 8:11 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KMDF Common Buffer DMA

Recognizing that this is no longer about the topic that started this
thread…

[quote]
If anyone knows how to return more than a status code to the application
sending a METHOD_OUT_DIRECT IOCTL, without resorting to manually
scribbling on the output buffer after the data is transferred to the
hardware, I’d really like to hear about it [/quote]

I guess the obvious question is: Why not have the OUT buffer contain a
data structure – perhaps with the offset/length within the OUT buffer
of the data you want sent TO the hardware and the offset/length within
the OUT buffer of a place to return data FROM the hardware? While not
an immediately obvious design, we’ve found it works quite well…

Or so you consider that “manually scribbling on the output buffer”??

Peter
OSR

Gary_Little-2 · June 9, 2006, 1:55pm

Not to mention that over time comments “migrate”, get “mangled”, and many
times end up having NOTHING whatsoever to do with what the code actually
does now.

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@probo.com
Sent: Friday, June 09, 2006 12:26 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] KMDF Common Buffer DMA

Brown, Beverly wrote:

You could always explain it in a comment so the next person will also
know why.

Comments? I’m supposed to put comments in my code?

I’ve always ascribed to the theory that “if it was hard to write, it
should be hard to read.”

–
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

Gary_Little-2 · June 9, 2006, 1:58pm

Don’t forget IOCTL_ATA_PASS_THROUGH_IN/OUT_DIRECT, while wishfully
thinking.

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Philip D Barila
Sent: Friday, June 09, 2006 12:21 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF Common Buffer DMA

Call me na?ve, but it doesn’t seem like it would be a gigantic IoManager
change to copy the contents of the input buffer back into user-mode on a
METHOD_OUT_DIRECT. Or both METHOD_*_DIRECT, for that matter. But the one
that is killer is METHOD_OUT_DIRECT, because you only get a status value
unless you use the caller’s buffer, which has it’s own issues I’m
addressing in another post.

How about it, Peter W or Doron, is that a reasonable change request to at
least put in the queue to scope?

As you say, Peter W, if you could do that, you could do away with a lot of
embedded pointers. So could I.

Personally, I’d love the idea of a IOCTL_SCSI_PASS_THROUGH_IN/OUT_DIRECT
which had no embedded pointers.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Friday, June 09, 2006 10:13 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF Common Buffer DMA

Sadly there isn’t without using METHOD_NEITHER or otherwise poking into
user-mode directly. This is the failing of METHOD_DIRECT_*. They’re
great ways to do command+one-way-data but they can’t do bi-directional
data and they can’t return complex status.

If we had a way to do command + bi-directional data + status in a single
I/O control without resulting to METHOD_NEITHER then we could get rid of
a lot of embedded pointers.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Thursday, June 08, 2006 3:31 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF Common Buffer DMA

…

If anyone knows how to return more than a status code to the application
sending a METHOD_OUT_DIRECT IOCTL, without resorting to manually
scribbling on the output buffer after the data is transferred to the
hardware, I’d really like to hear about it.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

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

Peter_Viscarola_OSR · June 9, 2006, 3:49pm

To me, this sounds like an ENORMOUS architectural change.

The IN buffer has always been used to passed data IN and (ignoring method_neither) always uses buffered I/O. It was designed, basically, as a buffer in which to pass parameters/modifiers into the driver.

The OUT buffer is designed to carry the payload.

I dunno. Maybe. The way we typically do this is to have the OUT buffer (for METHOD_OUT_DIRECT) contain a data-structure, like the following:

typedef struct _myDataBuffer {
ULONG OperationToPerform;
ULONG SomeOtherShite;
ULONG_PTR SomeAdditionalStatusInformation;
ULONG LengthOfDataForHardware;
ULONG_PTR ByteOffsetToStartOfDataForHardware;
ULONG LengthOfReturnDataBuffer;
ULONG_PTR ByteOffsetToStartOfReturnDataBuffer;
UCHAR StartOfBufferSpace;
} myDataBuffer, *PmyDataBuffer;

You’ll probably recognize the pattern… it’s the way lots of data is packed into a single buffer.

So, the user allocs the OUTbuffer as appropriate, fills in the structure, and sends it on up to the driver… no muss, no fuss, no bother.

The offset/length values are captured in the driver (usual secutiry procedures regarding METHOD_X_DIRECT apply) and are easy to validate (nothing can reach past the end of the buffer).

It seems easy and reasonable to me,

Peter
OSR

OSR_Community_User · June 9, 2006, 4:10pm

There are three problems with this:

The I/O manager won’t know how many bytes to copy back for the input buffer since we only have one Information field for the IRP. We’d have to invent a new one.
We don’t have any more METHOD bits in the I/O control so we don’t know when to apply this logic which leads to #3
The application isn’t expecting its InputBuffer to get overwritten and thus would very likely blow its brains out.

If it happens it needs to be describable in the I/O control contract (which at the moment consists of two method bits, two access bits and 28 other bits) and needs to work within the existing IRP/IO_STACK_LOCATION structures in a way which ensures it can’t get lost as it passes through other drivers that don’t understand the new semantic.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@seagate.com
Sent: Friday, June 09, 2006 10:21 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF Common Buffer DMA

Call me na?ve, but it doesn’t seem like it would be a gigantic IoManager change to copy the contents of the input buffer back into user-mode on a METHOD_OUT_DIRECT. Or both METHOD_*_DIRECT, for that matter. But the one that is killer is METHOD_OUT_DIRECT, because you only get a status value unless you use the caller’s buffer, which has it’s own issues I’m addressing in another post.

How about it, Peter W or Doron, is that a reasonable change request to at least put in the queue to scope?

As you say, Peter W, if you could do that, you could do away with a lot of embedded pointers. So could I.

Personally, I’d love the idea of a IOCTL_SCSI_PASS_THROUGH_IN/OUT_DIRECT
which had no embedded pointers.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Friday, June 09, 2006 10:13 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF Common Buffer DMA

Sadly there isn’t without using METHOD_NEITHER or otherwise poking into user-mode directly. This is the failing of METHOD_DIRECT_*. They’re great ways to do command+one-way-data but they can’t do bi-directional data and they can’t return complex status.

If we had a way to do command + bi-directional data + status in a single I/O control without resulting to METHOD_NEITHER then we could get rid of a lot of embedded pointers.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@seagate.com
Sent: Thursday, June 08, 2006 3:31 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF Common Buffer DMA

…

If anyone knows how to return more than a status code to the application sending a METHOD_OUT_DIRECT IOCTL, without resorting to manually scribbling on the output buffer after the data is transferred to the hardware, I’d really like to hear about it.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

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

OSR_Community_User · June 9, 2006, 5:23pm

Umm, yeah, overwriting the user buffer without them expecting it is one of
the things I said isn’t cool, isn?t it?

Color me silly. And still using embedded pointers. For all the annoyance
of getting it right the first time, it’s only something you have to get
right once.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Friday, June 09, 2006 2:08 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF Common Buffer DMA

There are three problems with this:

The I/O manager won’t know how many bytes to copy back for the input
buffer since we only have one Information field for the IRP. We’d have to
invent a new one.
We don’t have any more METHOD bits in the I/O control so we don’t know
when to apply this logic which leads to #3
The application isn’t expecting its InputBuffer to get overwritten and
thus would very likely blow its brains out.

If it happens it needs to be describable in the I/O control contract
(which at the moment consists of two method bits, two access bits and 28
other bits) and needs to work within the existing IRP/IO_STACK_LOCATION
structures in a way which ensures it can’t get lost as it passes through
other drivers that don’t understand the new semantic.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, June 09, 2006 10:21 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KMDF Common Buffer DMA

Call me na?ve, but it doesn’t seem like it would be a gigantic IoManager
change to copy the contents of the input buffer back into user-mode on a
METHOD_OUT_DIRECT. Or both METHOD_*_DIRECT, for that matter. But the one
that is killer is METHOD_OUT_DIRECT, because you only get a status value
unless you use the caller’s buffer, which has it’s own issues I’m
addressing in another post.

How about it, Peter W or Doron, is that a reasonable change request to at
least put in the queue to scope?

As you say, Peter W, if you could do that, you could do away with a lot of
embedded pointers. So could I.

Personally, I’d love the idea of a IOCTL_SCSI_PASS_THROUGH_IN/OUT_DIRECT
which had no embedded pointers.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842