[[Unable to retrieve message
84bdcc66.0412030325.70125378@posting.google.com]]
Thanks for your responses. It seems I have to be more specific as to
what I want, or why I thought an IM driver would be appropriate.
We (mis-)use NDISUIO/NDISPROT just as the interface from the miniport
to the user level which works well. However, it seems to me that
adding any "real" protocol in there would make things messy and hard
to maintain, since I would be mixing two things, a protocol
(manipulating contents) and a 1:1 packet to IRP packer (struggling
with OS issues).
So I thought I needed something to go between the miniport and the
"protocol", i.e. the user level interface, and the thing that seemed
to fit like a glove was an IM protocol driver. In there I thought I
could strip the 14 byte Ethernet header and the proprietary protocol
headers and trailers by just manipulating the MDL start address and
length and get away without any memcopies.
(I know it is not nice to assume that an NdisPacket will always
consist of N NdisBuffers which are just MDLs. I was also hoping that I
could somehow ensure that N=1. We work in a fairly special purpose
market, so the number of different Miniports we have to support are
fairly limited and stable.)
That way I could also modularly switch between different proprietary
protocols without having to duplicate the UIO part every time which is
fixed for any NIC and any protocol.
If IM protocol drivers are inappropriate for what I want, is there
another way to achieve these goals in XP? Can I put a second protocol
driver in the chain instead? Is there a sample for that? Is that
efficient, or do I have to work with IRPs and the I/O manager?
How is IP and TCP implemented in Windows? I hope they do not use IRPs
as the mechanism? I would assume that IP and TCP are separate, since
UDP and ARP work over IP without TCP, but then I only see one "entity"
to "tick" in the network properties dialog. I guess I was hoping for
something like STREAMS in System V, but enough rambling.
What we want to achieve? Get the data from the hardware into a
contiguous user level memory area FAST, removing the headers and
trailers of Ethernet and error detection/correction protocol on the
fly, sometimes rather infrequently the packet content needs to be
modified (on error correction). The normal case needs to be efficient,
the rare case not (obviously). At the same time the whole thing should
be easily maintainable and open to changes in the protocol or even
changes in the implementation of the same protocol, e.g. modular etc.
Thanks again for any help.
PS. Yes, I have tried to share memory between kernel and user, but I
still have to transfer the packet content from the NDIS data
structures to the shared memory and then copy again to remove the
headers and trailers.