pseudoSCSI miniport driver for iSCSI

NTDEV
1

greetings,

if there is someone out there who is familiar with SCSI miniports I
have a few questions.

I need to extend the pseudoSCSI miniport a bit beyond the DDK’s
definition of “interfacing a storage class driver and a SCSI miniport
that controls a nonSCSI storage device”.

I’m taking an iSCSI driver I wrote for Linux and I need to create a
similar driver for NT. This driver “fakes” an HBA, and re-routes all the
SCSI commands to a TCP interface. The system thinks there’s
a SCSI disk and treats it accordingly even though the hardware (an
NCR HBA) is not physically installed.

My questions are:

can a SCSi miniport driver successfully present a “dummy” HBA to
Windows? will the storage-port driver somehow foul this appraoch?

since I don’t have any interrupts to enable on an HBA inside of
HwScsiInitialize() will the port driver unload the miniport?

does NT send device ready requests to each LUN ID on the HBA
after DriverEntry()?

thanks,

Andy Villa
xxxxx@avilla.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

2

The best way IMHO is to write a SCSI PORT driver and forget about a
miniport. However writing a SCSI Port driver for NT is not documented and
not too easy (it is not documented). The advantage of doing your own port
driver is that you get out from all the interface restrictions imposed by
the miniport. To compound your problems, your going to have to figure
out how to talk to TCP via the TDI interface (not the easiest interface to
you.) Anyway, to continue. I say write a full scsi port driver. If
you do this, your second question is moot, Your going to be writing a
software only PNP driver NT. If you do your driver this way. You will
only make your devices visible to NT when you have a connection to them so
only then will NT start sending device ready requests. BTW, Microsoft
doesn’t currently WHQL scsi port drivers (at least I don’t think so).

Look at the toaster bus example in the DDK for a BUS driver, because that is
what your driver will be a SCSI BUS driver, you can look at a TDI example on
www.pcausa.com http: .

–Mark

Mark J. Cariddi
Consulting Associate
Open Systems Resources, Inc.
http://www.osr.com/

-----Original Message-----
From: avilla [mailto:xxxxx@avilla.com]
Sent: Saturday, March 17, 2001 3:21 PM
To: NT Developers Interest List
Subject: [ntdev] pseudoSCSI miniport driver for iSCSI

greetings,

if there is someone out there who is familiar with SCSI miniports I
have a few questions.

I need to extend the pseudoSCSI miniport a bit beyond the DDK’s
definition of “interfacing a storage class driver and a SCSI miniport
that controls a nonSCSI storage device”.

I’m taking an iSCSI driver I wrote for Linux and I need to create a
similar driver for NT. This driver “fakes” an HBA, and re-routes all the
SCSI commands to a TCP interface. The system thinks there’s
a SCSI disk and treats it accordingly even though the hardware (an
NCR HBA) is not physically installed.

My questions are:

can a SCSi miniport driver successfully present a “dummy” HBA to
Windows? will the storage-port driver somehow foul this appraoch?

since I don’t have any interrupts to enable on an HBA inside of
HwScsiInitialize() will the port driver unload the miniport?

does NT send device ready requests to each LUN ID on the HBA
after DriverEntry()?

thanks,

Andy Villa
xxxxx@avilla.com mailto:xxxxx

—
You are currently subscribed to ntdev as: xxxxx@osr.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</mailto:xxxxx></http:>

3

>My questions are:

can a SCSi miniport driver successfully present a “dummy” HBA to
Windows?

Yes.

will the storage-port driver somehow foul this appraoch?

Not as long as you go through the motions correctly. A pseudo driver (no
hardware) will work fine. You will however have some issues with accessing
the network stack, as essentially all of your miniport routines will be
running at DISPATCH_LEVEL. You can work around this but it is annoying. You
will also obviously not be portable outside of NT as you will be accessing
DDK functions in addition to Scsiport functions.

since I don’t have any interrupts to enable on an HBA inside of
HwScsiInitialize() will the port driver unload the miniport?

No interrupts is fine. Scsiport will assume that you are polling your ‘hba
device’.

does NT send device ready requests to each LUN ID on the HBA
after DriverEntry()?

Scsiport attemtps to enumerate each bus target and lun that you indicate
COULD exist on your mythical hardware. As part of that enumeration it will
send INQUIRY requests to LUN 0 of each target id. TEST_UNIT_READY might be
sent, but not by scsiport. (Classpnp might send it.) By default if Lun 0
does not respond to an inquiry scsiport does not look at any other luns on
that target.

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

> hardware) will work fine. You will however have some issues with accessing

the network stack, as essentially all of your miniport routines will be
running at DISPATCH_LEVEL. You can work around this but it is annoying.

Above DISPATCH_LEVEL usually. They are called from inside
KeSynchronizeExecution.

Max

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

5

I agree.

SCSIPORT that ships with Windows is not documented and it is designed to
work with hardware, not pseudo devices.

We wrote our own SCSI port driver with its own miniport interface. We
maintained compatibility with the MS miniport interface.

What we did was to deserialize the SCSI port to miniport interface. This
allows us to post IRPS to threads, use worker items and complete SCSI
requests in any context; no just the SCSIPORT context. So, calling TDI is a
breeze!

Works great. Study the class2.sys sources in the DDK. It uncovers a few bugs
in the SCSIPORT that MS worked around; we had to implement the bug to
maintain compatibility :slight_smile:

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Mark Cariddi
Sent: Saturday, March 17, 2001 12:31 PM
To: NT Developers Interest List
Cc: xxxxx@avilla.com
Subject: [ntdev] RE: pseudoSCSI miniport driver for iSCSI

The best way IMHO is to write a SCSI PORT driver and forget about a
miniport. However writing a SCSI Port driver for NT is not documented and
not too easy (it is not documented). The advantage of doing your own port
driver is that you get out from all the interface restrictions imposed by
the miniport. To compound your problems, your going to have to figure
out how to talk to TCP via the TDI interface (not the easiest interface to
you.) Anyway, to continue. I say write a full scsi port driver. If
you do this, your second question is moot, Your going to be writing a
software only PNP driver NT. If you do your driver this way. You will
only make your devices visible to NT when you have a connection to them so
only then will NT start sending device ready requests. BTW, Microsoft
doesn’t currently WHQL scsi port drivers (at least I don’t think so).

Look at the toaster bus example in the DDK for a BUS driver, because that
is what your driver will be a SCSI BUS driver, you can look at a TDI example
on www.pcausa.com.

–Mark
Mark J. Cariddi
Consulting Associate
Open Systems Resources, Inc.
http://www.osr.com/

-----Original Message-----
From: avilla [mailto:xxxxx@avilla.com]
Sent: Saturday, March 17, 2001 3:21 PM
To: NT Developers Interest List
Subject: [ntdev] pseudoSCSI miniport driver for iSCSI

greetings,

if there is someone out there who is familiar with SCSI miniports I
have a few questions.

I need to extend the pseudoSCSI miniport a bit beyond the DDK’s
definition of “interfacing a storage class driver and a SCSI miniport
that controls a nonSCSI storage device”.

I’m taking an iSCSI driver I wrote for Linux and I need to create a
similar driver for NT. This driver “fakes” an HBA, and re-routes all
the
SCSI commands to a TCP interface. The system thinks there’s
a SCSI disk and treats it accordingly even though the hardware (an
NCR HBA) is not physically installed.

My questions are:

can a SCSi miniport driver successfully present a “dummy” HBA to
Windows? will the storage-port driver somehow foul this appraoch?

since I don’t have any interrupts to enable on an HBA inside of
HwScsiInitialize() will the port driver unload the miniport?

does NT send device ready requests to each LUN ID on the HBA
after DriverEntry()?

thanks,

Andy Villa
xxxxx@avilla.com

You are currently subscribed to ntdev as: xxxxx@osr.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@storagecraft.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

6

Jamey,

Using your SCSI port driver can I exceed 128K for a data block size?

Gary

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Jamey Kirby
Sent: Saturday, March 17, 2001 3:27 PM
To: NT Developers Interest List
Cc: xxxxx@avilla.com
Subject: [ntdev] RE: pseudoSCSI miniport driver for iSCSI

I agree.

SCSIPORT that ships with Windows is not documented and it is designed to
work with hardware, not pseudo devices.

We wrote our own SCSI port driver with its own miniport interface. We
maintained compatibility with the MS miniport interface.

What we did was to deserialize the SCSI port to miniport interface. This
allows us to post IRPS to threads, use worker items and complete SCSI
requests in any context; no just the SCSIPORT context. So, calling TDI is a
breeze!

Works great. Study the class2.sys sources in the DDK. It uncovers a few bugs
in the SCSIPORT that MS worked around; we had to implement the bug to
maintain compatibility :slight_smile:

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Mark Cariddi
Sent: Saturday, March 17, 2001 12:31 PM
To: NT Developers Interest List
Cc: xxxxx@avilla.com
Subject: [ntdev] RE: pseudoSCSI miniport driver for iSCSI
The best way IMHO is to write a SCSI PORT driver and forget about a
miniport. However writing a SCSI Port driver for NT is not documented and
not too easy (it is not documented). The advantage of doing your own port
driver is that you get out from all the interface restrictions imposed by
the miniport. To compound your problems, your going to have to figure
out how to talk to TCP via the TDI interface (not the easiest interface to
you.) Anyway, to continue. I say write a full scsi port driver. If
you do this, your second question is moot, Your going to be writing a
software only PNP driver NT. If you do your driver this way. You will
only make your devices visible to NT when you have a connection to them so
only then will NT start sending device ready requests. BTW, Microsoft
doesn’t currently WHQL scsi port drivers (at least I don’t think so).

Look at the toaster bus example in the DDK for a BUS driver, because that is
what your driver will be a SCSI BUS driver, you can look at a TDI example on
www.pcausa.com http: .

–Mark
Mark J. Cariddi
Consulting Associate
Open Systems Resources, Inc.
http://www.osr.com/
-----Original Message-----
From: avilla [mailto:xxxxx@avilla.com]
Sent: Saturday, March 17, 2001 3:21 PM
To: NT Developers Interest List
Subject: [ntdev] pseudoSCSI miniport driver for iSCSI
greetings,

if there is someone out there who is familiar with SCSI miniports I
have a few questions.

I need to extend the pseudoSCSI miniport a bit beyond the DDK’s
definition of “interfacing a storage class driver and a SCSI miniport
that controls a nonSCSI storage device”.

I’m taking an iSCSI driver I wrote for Linux and I need to create a
similar driver for NT. This driver “fakes” an HBA, and re-routes all the
SCSI commands to a TCP interface. The system thinks there’s
a SCSI disk and treats it accordingly even though the hardware (an
NCR HBA) is not physically installed.

My questions are:

can a SCSi miniport driver successfully present a “dummy” HBA to
Windows? will the storage-port driver somehow foul this appraoch?

since I don’t have any interrupts to enable on an HBA inside of
HwScsiInitialize() will the port driver unload the miniport?

does NT send device ready requests to each LUN ID on the HBA
after DriverEntry()?

thanks,

Andy Villa
xxxxx@avilla.com mailto:xxxxx

—
You are currently subscribed to ntdev as: xxxxx@osr.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@delphieng.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</mailto:xxxxx></http:>

7

Mark Roddy
Windows 2000/NT Consultant
Hollis Technology Solutions
xxxxx@hollistech.com
603 321 1032
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Saturday, March 17, 2001 5:31 PM
To: NT Developers Interest List
Subject: [ntdev] RE: pseudoSCSI miniport driver for iSCSI

> hardware) will work fine. You will however have some issues
with accessing
> the network stack, as essentially all of your miniport routines will be
> running at DISPATCH_LEVEL. You can work around this but it is annoying.

Above DISPATCH_LEVEL usually. They are called from inside
KeSynchronizeExecution.

Max

Not in his case, he has no hardware, so scsiport cant use
KeSynchronizeExecution as it has no InterruptObject for his device.

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

8

The data block size limit is usually determined by the underlying host adapters
scatter/gather limits, not by SCSIPORT (although SCSIPORT does implements the
necessary checks).

Regards,

Paul Bunn, UltraBac.com, 425-644-6000
Microsoft MVP - WindowsNT/2000
http://www.ultrabac.com

-----Original Message-----
From: Gary G. Little [mailto:xxxxx@inland.net]
Sent: Saturday, March 17, 2001 5:33 PM
To: NT Developers Interest List
Cc: xxxxx@avilla.com
Subject: [ntdev] RE: pseudoSCSI miniport driver for iSCSI

Jamey,

Using your SCSI port driver can I exceed 128K for a data block size?

Gary

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]On
Behalf Of Jamey Kirby
Sent: Saturday, March 17, 2001 3:27 PM
To: NT Developers Interest List
Cc: xxxxx@avilla.com
Subject: [ntdev] RE: pseudoSCSI miniport driver for iSCSI

I agree.

SCSIPORT that ships with Windows is not documented and it is designed to work with
hardware, not pseudo devices.

We wrote our own SCSI port driver with its own miniport interface. We maintained
compatibility with the MS miniport interface.

What we did was to deserialize the SCSI port to miniport interface. This allows us
to post IRPS to threads, use worker items and complete SCSI requests in any
context; no just the SCSIPORT context. So, calling TDI is a breeze!

Works great. Study the class2.sys sources in the DDK. It uncovers a few bugs in
the SCSIPORT that MS worked around; we had to implement the bug to maintain
compatibility :slight_smile:

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

9

Hi Andy,

Yes you can write the SCSI miniport in this way. I’ve just completed such a
project myself. SCSI miniport (or full port driver, I’ve used full port in
prototyping while miniport was used for release version), talking to TDI
client driver that handles all network requests and other driver that
handles local caching with files. If you have some questions you can write
to my e-mail.

Regards,
Anton

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

10

> Hi Andy,

Yes you can write the SCSI miniport in this way. I’ve just completed such
a
project myself. SCSI miniport (or full port driver, I’ve used full port in
prototyping while miniport was used for release version), talking to TDI
client driver that handles all network requests and other driver that

How did you manage to bypass the miniport context limitation?
From what context do you call ScsiPortNotification(RequestComplete…)?

SCSIPORT mandates this to be called from the miniport context - i.e. from
one of the Miniportxxx functions called by SCSIPORT itself. The reason is
that SCSIPORT acquires 2 spinlocks (one by KeSynchronizeExecution) before
calling Miniportxxx and then expects ScsiPortNotification from being called
with these locks acquired.
Do you use RequestTimerCall feature of SCSIPORT to enter the miniport
context?

Max

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

11

>How did you manage to bypass the miniport context limitation?

From what context do you call ScsiPortNotification(RequestComplete…)?

From context of the miniport surely. If RequestComplete will be called from
the other context it seems that SCSIPORT just ignores this completion. SRB
is cancelled as timeouted.

SCSIPORT mandates this to be called from the miniport context - i.e. from
one of the Miniportxxx functions called by SCSIPORT itself. The reason is
that SCSIPORT acquires 2 spinlocks (one by KeSynchronizeExecution) before
calling Miniportxxx and then expects ScsiPortNotification from being
called with these locks acquired.

So?

Do you use RequestTimerCall feature of SCSIPORT to enter the miniport
context?

Surely. As all people I know do. I do not know the best way… And any
other way as well. This results request latency but has a pluses -> very
low CPU usage comparing with the port driver that handles that requests by
it’s own…

// some code goes here…

//
// initiate timer callback
//
ScsiPortNotification(
RequestTimerCall,
pMiniGunDeviceExtension,
MiniGunTimerCallback,
MINIGUN_TIMER_INTERVAL
);

//
// set status to pending
//
return SRB_STATUS_PENDING;
}

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

12

> >Do you use RequestTimerCall feature of SCSIPORT to enter the miniport

>context?

Surely. As all people I know do. I do not know the best way… And any
other way as well. This results request latency but has a pluses -> very

This has no pluses. This limits the throughput of the miniport by the poll
frequency.
Not good at all in case if the upper-layer FSD or the app will send a
sequence of requests - read, wait for completion, then write, then wait for
completion, then write once more, wait for completion…
In this case, each IO operation will take the time specified by your timer
tick period.

Max

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

13

Max is correct. You MUST write your own SCSI port driver to get around the
issues.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Thursday, March 22, 2001 4:19 AM
To: NT Developers Interest List
Subject: [ntdev] Re: pseudoSCSI miniport driver for iSCSI

> >Do you use RequestTimerCall feature of SCSIPORT to enter the miniport
> >context?
>
> Surely. As all people I know do. I do not know the best way… And any
> other way as well. This results request latency but has a pluses -> very

This has no pluses. This limits the throughput of the miniport by the poll
frequency.
Not good at all in case if the upper-layer FSD or the app will send a
sequence of requests - read, wait for completion, then write,
then wait for
completion, then write once more, wait for completion…
In this case, each IO operation will take the time specified by your timer
tick period.

Max

You are currently subscribed to ntdev as: xxxxx@storagecraft.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

14

> >Do you use RequestTimerCall feature of SCSIPORT to enter the miniport

>context?

Surely. As all people I know do. I do not know the best way… And any
other way as well. This results request latency but has a pluses -> very

This has no pluses. This limits the throughput of the miniport by the
poll
frequency.

I understand this. And the same concerns my customers and most of the
people who read this mail list.

Not good at all in case if the upper-layer FSD or the app will send a
sequence of requests - read, wait for completion, then write, then wait
for completion, then write once more, wait for completion…
In this case, each IO operation will take the time specified by your
timer
tick period.

Max this is all a question of time and money mostly. Until I have $12K and
2 month for the project I even will not start developing something that I
have not ever did. If you’re so lucky and got $100K for the project and
your customer can wait for at least half a year you may try to enjoy
yourself. I’m not so lucky right now. That’s all…

AK

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

15

>Max is correct. You MUST write your own SCSI port driver to get around
the

issues.

Surely. When somebody will ask me to do this not for free.

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

16

Ahhh, call it a LEARNING experience!!!

Gary G. Little
Sr. Staff Engineer
Broadband Storage, LLC
xxxxx@broadstor.com
xxxxx@delphieng.com

-----Original Message-----
From: xxxxx@hotmail.com
[mailto:xxxxx@hotmail.com]
Sent: Thursday, March 22, 2001 10:25 PM
To: NT Developers Interest List
Subject: [ntdev] Re: pseudoSCSI miniport driver for iSCSI

Max is correct. You MUST write your own SCSI port driver to get around
the
issues.

Surely. When somebody will ask me to do this not for free.

You are currently subscribed to ntdev as: xxxxx@delphieng.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