Thanks Gary for your feedbacks. As you wrote
Your load order indicates to me that you want a bus driver to control
the bus, including the IO and interrupts. Is that correct?
Yes, this is correct. Bus driver will own the hardware but it exposes
direct entry points to be used by SCSI Miniport. So Bus Driver DPC can
function as ScsiPort’s DPC. You probably are right with all these
performance and usability issues but to reach there we need to load
these two drivers in order. Is it technically not possible to load a
driver before SCSI Miniport driver?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Friday, August 05, 2005 1:13 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] How to load a Virtual Bus driver before SCSI
Miniport.
How to load a Virtual Bus driver before SCSI Miniport.Actually no. How
could
there be, when a virtual SCSI miniport is impossible using either
SCSIPORT
or STORPORT. You can do virtual SCSI minipoorts using 3rd party
software,
but not the port drivers included with Windows NT and above. Your load
order
indicates to me that you want a bus driver to control the bus, including
the
IO and interrupts. Is that correct? On top of that you want to float a
SCSI
min-port chlid. This child will then use the bus driver for it’s IO,
allowing other interfaces, as enumerated by the bus driver, to share
this
resource. Is that correct?
The bottom line is a SCSI miniport cannot be virtualized.
The last time this was brought up, the poor soul could not get into his
FindAdapter function, but what he did not realize is that he still had
the
unsolvable problem of through-put, because unless ScsiPort has access to
the
interrupt, there is no way to get ScsiPort’s DPC routine scheduled other
than the timer. Using the timer, you will incur a 10 ms delay in EVERY
FRIGGING SRB you have to complete. Some how or another, the bottom layer
in
this stack of cards has to be HBA/ScsiMiniPort/SCSIPORT. Any other way
will
either fail, be so damn slow that no-one in their right mind will ever
buy
it, or so full of system compromises that no one in their right mind
would
let it in the door, let alone pay money for something that uses it.
–
The personal opinion of
Gary G. Little
“Kumar, Dinesh” wrote in message
news:xxxxx@ntdev…
Hi,
I know there are lots of Virtual SCSI Experts on this mailing list. I am
writing a SCSI Miniport driver that depends on a virtual bus driver (Bus
driver is also mine). The SCSI Driver talks to bus driver to access the
hard
Disk. So I need to have bus driver loaded and initialized before my SCSI
driver can be initialized and access the disk. If I have the Operating
system installed on this disk and restart the system it always brings
the
SCSI Miniport first which in this case can not access the disk as bus
driver
is not yet initialized and so OS boot cannot start. If I am booting from
another disk (not controlled by My SCSI Miniport) than these two drivers
load in order and I can access my disk fine after System boots. Is there
a
way I can force OS to always load Virtual Bus driver before SCSI
Miniport.
SCSI Miniport PDO is created by this virtual Bus driver.
For Bus Driver I am setting the Group as “Boot Bus Extender” and start
as 0.
For SCSI Miniport I am setting Group as “SCSI miniport” and start as 0.
As per DDK the Group “Boot Bus Extender” drivers should be loaded before
“SCSI miniport”.
-Dinesh
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@intel.com
To unsubscribe send a blank email to xxxxx@lists.osr.com