FYI:
Please be careful using Virtual SCSI terminology and be aware that Advanced
Storage Concepts, Inc. has a published trademark, ‘VirtualSCSI’. Thanks
very much.
Bill Casey
== SCSI Adapters & VirtualSCSI™ Target Mode Libs ==
Advanced Storage Concepts, Inc. (409) 744-2129
2720 Terminal Drive xxxxx@virtualscsi.com
Galveston, TX 77554 USA www.virtualscsi.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, August 29, 2001 2:20 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Virtual SCSI miniports + requests comlpletion…Mark,
>I think your design works. You appear to have done your homework.
“Homework”. This is really the best name for this task -)
> If I understand, then your workitem IOCTL_SCSI_MINIPORT irps are
> targeted at a ‘special’ dummy LU that exists for the sole purpose
> of initiating the completion of other SRBs.Exactly. This is second variant of the “homework” solution.
> This works for me, and I think there is no major design issue other
> than that you are working outside the boundaries of the
> scsiport/miniport framework.You see… This is virtual driver. It does not attach to any real
hardware. In the other time it does “something”. And most of
this “something” (like calling Zw* file I/O code, calling TDI etc)
must be done from the PASSIVE_LEVEL and in known (better system)
context. So I’ll just have to work outside the boundaries of the
SCSIPORT/miniport if I want my driver to do some work. There is
no overhead. Worker threads/items are the tools that will be with
virtual drivers. It does not matter will this drivers be full port or
only miniport drivers, will they use timer callback to complete
SRBs or will they use other approach - worker threads/items will
be with them. Using them to complete the requests in SCSIPORT
miniports is just other task for them. One more. But not the only
one -)> You might want to consider a worker thread/work queue/event
> model rather than queueing a workitem per SRB, but that is a
> performance, rather than a design issue.Right. Optimization goes next… But “will it work or will it
crash b/s of ideological reasons?” that was the question. And I’m
not intereted much in optimization as I’m going to use SCSI port
driver not MS SCSIPORT miniports.And do you want to know the most interesting thing? I’ve tested the
first variant of the solution. The one where LU sends SRBs to
itself to complete own requests. See my SCSI miniport was written
in the way it was not using MultipleRequestPerLu so it was harder
for me to test the “civil” solution. That’s why I went first with
the one with real “self-call”. Where I had to set pScsiRequestBlock->
SrbFlags = ( SRB_FLAGS_DATA_IN | SRB_FLAGS_NO_QUEUE_FREEZE |
SRB_FLAGS_BYPASS_FROZEN_QUEUE ) and call the SCSIPORT with IRP_MJ_SCSI
and some vendor-specific SCSI opcode to complete the request.
This works as well! And does not require extra logical unit and
significant miniport code modification (when someone’s miniport
does not support multiple requests per logical unit). So I think
this solution to my “homework” has right to live too. I’ve
checked the source code of the disk class driver and it seems to
utilize explict queue flags (disk class driver tells SCSIPORT how
to queue the IRPs) just as I do (well, very close to what I do).With respect,
Anton Kolomyeytsev
You are currently subscribed to ntdev as: xxxxx@advstor.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.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
