Re: which kind of driver to design for AoE protocol?
- From: soviet_bloke@xxxxxxxxxxx
- Date: 20 Aug 2006 22:08:30 -0700
Hi mate
just to clarify a detail about the protocol: it's connectionless, so TCP and
UDP are not need or used...it's LAN only, not internet capable.
Please see the official (8 page) protocol for details
(http://www.coraid.com/documents/AoEr10.txt).
Figured this might really change some of the assumptions on what was
necessary, and therefore how to accomplish the goal.
Unfortunately, it does not make your life easier at all........
I was not sure whether the existing protocol stack may handle requests
at raised IRQL, so that I thought you may need to write your own
protocol driver. As guys have explained to me, I was worried about
non-existent "problem", so that protocol driver is not needed.
Now it turns out that protocol driver may be needed for totally
different reasons........
I don't know if it suits your needs, but you can implement your
protocol over UDP
(i.e. more or less the same way VPN drivers implement PPP over TCP),
effectively eliminating the need for a separate protocol driver. If you
do it this way, you will reduce the complexity of your task
dramatically.....
Anton Bassov
Ebola_Influenza wrote:
Hello again, it's the OP...
just to clarify a detail about the protocol: it's connectionless, so TCP and
UDP are not need or used...it's LAN only, not internet capable.
Please see the official (8 page) protocol for details
(http://www.coraid.com/documents/AoEr10.txt).
Figured this might really change some of the assumptions on what was
necessary, and therefore how to accomplish the goal.
I greatly appreciate the banter so far...just trying to keep up.
Best,
EI
"soviet_bloke@xxxxxxxxxxx" wrote:
Hi Thomas
But for sure living with the limitations of TdiBuildInternalDeviceControlIrp
is an unnecessary impediment. Understand this this limitation is because
TdiBuildInternalDeviceControlIrp is a MACRO around
IoBuildDeviceIoControlRequest. IoBuildDeviceIoControlRequest is the culprit
because it can only be called at IRQL == PASSIVE_LEVEL.
I am afraid there may be the problem not only with allocating IRP, but
with actually sending it - I am not 100% sure Dispatch routine of
TCPIP.SYS is ready to receive
TDI requests at raised IRQL. Please read my message to Maxim - I have
expresssed all my considerations (although, probably, unfounded ones)
there. It would be great if you could express your opinion on this
subject - after all, you are well-known expert in all network-related
internal stuff
Anton Bassov
Thomas F. Divine [DDK MVP] wrote:
<soviet_bloke@xxxxxxxxxxx> wrote in message
news:1155996486.266582.54030@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi DonCertainly such a driver is not easy.
Why would I have to allocate IRP's? You have an IRP comming down with
the
request from the storage stack, if the virtual port driver is attached
properly to TDI, this can be in some instances as easy as just filling in
the next stack location. This is the reason for stack locations in
IRP's!!!!
Do you really think it is a good idea to make your driver part of a
network stack?????
Look - if you want to read or write data from some remote location, you
have to send TDI request to underlying driver, and they are always in
the form of IRP_MJ_INTERNAL_DEVICE_CONTROL request. Therefore, in order
to handle
IRP_MJ_READ or IRP_MJ_WRITE request that you have received, you need to
send IRP_MJ_INTERNAL_DEVICE_CONTROL to underlying network driver.
Therefore, you would hardly achieve anything by attaching your device
to the network stack.
In actuality, this is not even the question of allocating IRPs, but
more of sending it - once TDI drivers are expected to receive
synchronous requests that have been allocated with
TdiBuildInternalDeviceControlIrp() and built with TdiBuildXXX(), there
is a good chance that they may expect to receive all TDI requests at
IRQL<DISPATCH_LEVEL
To summarize, things are not necessarily that easy
Anton Bassov
But for sure living with the limitations of TdiBuildInternalDeviceControlIrp
is an unnecessary impediment. Understand this this limitation is because
TdiBuildInternalDeviceControlIrp is a MACRO around
IoBuildDeviceIoControlRequest. IoBuildDeviceIoControlRequest is the culprit
because it can only be called at IRQL == PASSIVE_LEVEL.
There are ways around this particular limitation. Allocate IRPS beforehand
when it is safe to do so and reuse them when at higher IRQL. Stash them in
an SLIST and reuse the IRPs instead of freeing them. In most practical cases
you probably want have too many IRPs in-flight.
Note also that IoAlocateIrp can be called at DISPATCH_LEVEL, so you can
always build your IRP at DISPATCH level instead of using
TdiBuildInternalDeviceControlIrp.
Good luck,
Thomas F. Divine, Windows DDK MVP
http://www.pcausa.com
.
- Follow-Ups:
- Re: which kind of driver to design for AoE protocol?
- From: Ebola_Influenza
- Re: which kind of driver to design for AoE protocol?
- References:
- Re: which kind of driver to design for AoE protocol?
- From: Don Burn
- Re: which kind of driver to design for AoE protocol?
- From: soviet_bloke
- Re: which kind of driver to design for AoE protocol?
- From: Don Burn
- Re: which kind of driver to design for AoE protocol?
- From: soviet_bloke
- Re: which kind of driver to design for AoE protocol?
- From: Thomas F. Divine [DDK MVP]
- Re: which kind of driver to design for AoE protocol?
- From: soviet_bloke
- Re: which kind of driver to design for AoE protocol?
- From: Ebola_Influenza
- Re: which kind of driver to design for AoE protocol?
- Prev by Date: driver update delima
- Next by Date: Allocating memory in a filter hook driver callback function
- Previous by thread: Re: which kind of driver to design for AoE protocol?
- Next by thread: Re: which kind of driver to design for AoE protocol?
- Index(es):
Relevant Pages
|
