Prev: How to show media/cable disconnected
Next: Printer Name Issue
From: Maxim S. Shatskih on 24 Jul 2006 00:26
> once NdisIndicatePacket() returned, you were safe to free up resources

No. You only can free resources in MiniportReturnPacket callback.

> Then, say I get a sixth read completion from the bulk endpoint. Now
> I'm out of buffers

Replenish the set of buffers if it drops too low.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim(a)storagecraft.com
http://www.storagecraft.com

From: Maxim S. Shatskih on 24 Jul 2006 00:28
> freed up -- in WDM land I've gotten blue screened by worker threads
> which were not cleaned up by DriverUnload() time (even after
> synchronizing their exits with a KEVENT -- had to insert some sleep
> statements..)

Use IoQueueWorkItem instead of ExQueueWorkItem.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim(a)storagecraft.com
http://www.storagecraft.com

From: Doron Holan [MS] on 24 Jul 2006 01:12
> I'm assuming the process would be
> something like: create a work item, watch for the "free receive
> resource" count to increase above zero, and so on.
too complicated. just put the packet into a list. manage the list state
under a spinlock. when MiniportReturnPacket is called, grab the lock and
check the list to see if there is anything to indicate immediately. this
way you don't have a pending work item. on device remove you just free the
entries in the list.

> In the latter case, I have to wonder what the endgame is for a
> simulated scenario where NDIS is not flushing any of my indicated
> packets and I keep queuing up more and more receive buffers -- I could
> imagine a test case in the NDIS tester that just does this, although I
> have not checked.
then put a limit on the number of buffers you queue in the list. make it
something rather high i would guess. for tcp/ip, if you drop packets, no
big deal since the sender will resend them

> This seems like a lot of work just to use a USB continuous reader -- is
> there anything inherently disadvantageous about just reusing vanilla
> USB read requests, especially given that the NDISEDGE driver has the
> skeleton code for doing so?
trust me, you want to use the continuous reader. it is in KMDF b/c i have
seen so many drivers try to implement it and completely fail. The devil is
in the details, esp when canceling/stopping the reads when state changes
(like powering down due to standby)

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


<chris.aseltine(a)gmail.com> wrote in message
news:1153710338.747514.176690(a)h48g2000cwc.googlegroups.com...
> Doron Holan [MS] wrote:
>
>> > Then, say I get a sixth read completion from the bulk endpoint. Now
>> > I'm out of buffers, but I need to do something with the data that I
>> > just read in. What would I do in this situation?
>>
>> either queue the data and wait for one of your receive resources to be
>> returned or allocate a new receive resource on the fly. I am pretty sure
>> the point of preallocating the resources it make sure you can make fwd
>> progress and that you are not allocating in the recv path on every
>> packet.
>
> Well, in the former case, that sounds like a reasonable solution,
> although being a driver novice, I feel implementing that might take me
> into blue screen territory. I'm assuming the process would be
> something like: create a work item, watch for the "free receive
> resource" count to increase above zero, and so on.
>
> Then, (presumably, based on other driver work I've done) I also have to
> watch for a device disconnection (or other similar events) that would
> require unloading the driver, which would then in turn need to flush
> all the work items that are waiting for these receive resources to be
> freed up -- in WDM land I've gotten blue screened by worker threads
> which were not cleaned up by DriverUnload() time (even after
> synchronizing their exits with a KEVENT -- had to insert some sleep
> statements..)
>
> In the latter case, I have to wonder what the endgame is for a
> simulated scenario where NDIS is not flushing any of my indicated
> packets and I keep queuing up more and more receive buffers -- I could
> imagine a test case in the NDIS tester that just does this, although I
> have not checked. Would I need to call WdfIoTargetStop to temporarily
> halt the continuous reader?
>
> This seems like a lot of work just to use a USB continuous reader -- is
> there anything inherently disadvantageous about just reusing vanilla
> USB read requests, especially given that the NDISEDGE driver has the
> skeleton code for doing so?
>
> Please understand by no means am I trying to argue, since I'm sure your
> experience far outweighs mine :), but I'm just trying to think through
> the implications of each approach before I commit time to implementing
> either one.
>
> Thanks again.
>
> -Chris
>


From: Steve Dispensa on 24 Jul 2006 18:05
On 2006-07-21 13:41:38 -0500, chris.aseltine(a)gmail.com said:
> 2) The driver will need to have a "management" interface that can be
> accessed from user mode, i.e. DeviceIoControl().
....
> NdisMRegisterDevice(). This seems to be just what I need. Can someone
> confirm this will work for talking to the driver directly?

Yep, works like a champ.

> Also, if I
> were to look for this device with SetupDiEnumDeviceInterfaces(), which
> GUID would I use? I don't see a GUID argument to that call.

It creates a named device object, so you just access it by name - no
need of using GUIDs or SetupDi* calls at all.

> 3) This may not make any sense, but how much more difficult would it
> be to separate the USB and NDIS functions of the driver into two
> separate .sys drivers, with the NDIS driver communicating to the USB as
> a lower filter? Someone said this might cause confusion over power
> policies and so on.

Could be done; you'd have to think carefully about how the two
interact. In that case, your miniport would probably look something
like the netvmini sample.

I don't know anything about ndisedge, but if that's the officially
supported way of doing this with KMDF, you should probably start there
unless you run into an insurmountable problem.

-sd


From: chris.aseltine on 24 Jul 2006 19:19
Steve Dispensa wrote:

> > Also, if I
> > were to look for this device with SetupDiEnumDeviceInterfaces(), which
> > GUID would I use? I don't see a GUID argument to that call.
>
> It creates a named device object, so you just access it by name - no
> need of using GUIDs or SetupDi* calls at all.

Okay, (and I'm probably being obtuse here) -- so say I name it
\Device\MyUsbDevice001, 002, 003, etc. (this driver definitely needs to
support multiple devices being present on the system at once.)

What mechanism would I use from userspace to determine which
MyUsbDevice* named device objects are present on the system?

Would I need to just start from 001 and probe with CreateFile until I
get an invalid handle as my return value?

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: How to show media/cable disconnected
Next: Printer Name Issue