Deserialized NDIS Drivers

NTDEV
1

I’m in the process of converting an NDIS 4 driver to an NDIS 5 driver. In
the process, I’m trying to deserialize the driver. I thought the docs said
that a deserialized driver never sends NDIS_STATUS_PENDING in response to a
MiniportSendPackets() call, but the E100BEX sample does.

Other deserialized questions that I haven’t been able to figure out from
the docs (and I may have asked one of these before):

In the docs for packet reception, it says that a deserialized driver should
not look at the OOB packet status (NDIS_GET_PACKET_STATUS) after calling
NdisMIndicateReceivePacket(), that the status should be saved first. Why
would a deserialized driver indicate anything other than
NDIS_STATUS_SUCCESS up to NDIS? If it’s not success, retain the packet and
reset it yourself!

I’m just double-checking on this one, but EVERY packet processed by
MiniportSendPackets needs to be NdisMSendComplete’ed, right?

Thanks,

Scott

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

2

> ----------

From:
xxxxx@troikanetworks.com[SMTP:xxxxx@troikanetworks.com]
Reply To: NT Developers Interest List
Sent: Wednesday, August 01, 2001 3:36 PM
To: NT Developers Interest List
Subject: [ntdev] Deserialized NDIS Drivers

I’m in the process of converting an NDIS 4 driver to an NDIS 5 driver. In

the process, I’m trying to deserialize the driver. I thought the docs
said
that a deserialized driver never sends NDIS_STATUS_PENDING in response to
a
MiniportSendPackets() call, but the E100BEX sample does.

What do you mean by ‘deserialized driver never sends’? MiniportSendPackets
is a void function. I haven’t noticed this handler uses NDIS_STATUS_PENDING
any way (e100bex sample from XP DDK).

From docs:

The NDIS library ignores the OOB block in all packet descriptors it submits
to the MiniportSendPackets functions of deserialized drivers and assumes
that all deserialized miniports will complete each packet descriptor input
to their MiniportSendPackets functions asynchronously with
NdisMSendComplete. Consequently, such a deserialized driver’s
MiniportSendPackets function usually ignores the Status member of the
NDIS_PACKET_OOB_DATA block, but it can set this member to the same status as
it subsequently passes to NdisMSendComplete.

Other deserialized questions that I haven’t been able to figure out from
the docs (and I may have asked one of these before):

In the docs for packet reception, it says that a deserialized driver
should
not look at the OOB packet status (NDIS_GET_PACKET_STATUS) after calling
NdisMIndicateReceivePacket(), that the status should be saved first. Why
would a deserialized driver indicate anything other than
NDIS_STATUS_SUCCESS up to NDIS? If it’s not success, retain the packet
and
reset it yourself!

It may set status to NDIS_STATUS_RESOURCES to indicate it wants to reuse
packet immediately after NdisMIndicateReceivePacket() return. It must not
touch OOB packet status after indication probably because of race condition
with MiniportReturnPacket. Docs doesn’t completely explain this point, ms
decides it is better to make “rules” than explain why.

I’m just double-checking on this one, but EVERY packet processed by
MiniportSendPackets needs to be NdisMSendComplete’ed, right?

Sure. But it seems setting OOB status to anything for internal reasons
(queuing) isn’t a bug because NDIS doesn’t use it. It must be set to correct
value just before completion.

Best regards,

Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.com]

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

3

On 08/01/01, “Michal Vodicka ” wrote:
> What do you mean by ‘deserialized driver never sends’? MiniportSendPackets
> is a void function. I haven’t noticed this handler uses NDIS_STATUS_PENDING
> any way (e100bex sample from XP DDK).

My poor phrasing. I meant to say sets the OOB data. Oh, and the W2K DDK
e100bex sample does set the OOB to that (see the end of D100MultipleSend()
in send.c).

[other comments deleted for space]

Thanks for your comments, Michal.

Scott

—
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

4

> ----------

From:
xxxxx@troikanetworks.com[SMTP:xxxxx@troikanetworks.com]
Reply To: NT Developers Interest List
Sent: Wednesday, August 01, 2001 6:48 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Deserialized NDIS Drivers

On 08/01/01, “Michal Vodicka ” wrote:
> > What do you mean by ‘deserialized driver never sends’?
> MiniportSendPackets
> > is a void function. I haven’t noticed this handler uses
> NDIS_STATUS_PENDING
> > any way (e100bex sample from XP DDK).
>
> My poor phrasing. I meant to say sets the OOB data. Oh, and the W2K DDK
> e100bex sample does set the OOB to that (see the end of D100MultipleSend()
>
> in send.c).
>
Yes, you’re right. Maybe this code was cloned from serialized version and it
was forgotten. Or maybe it was necessary for some earlier NDIS version which
introduce deserialized support. I noticed some differences in NT4 where
deserialized drivers weren’t documented. Who knows, it was removed in XP
sample version and if docs is correct, it shouldn’t cause any problem.

Best regards,

Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.com]

—
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