SCSI filtering again

NTDEV
1

First, I’m trying to write arbitrary CDBs to SCSI devices (don’t worry, this
is a lab diagnostic/test app, it won’t ever end up on your customer’s
systems to cause the problems obvious and subtle this approach makes
trivial) at a queue depth greater than 1 (one) on Win2K/XP, so I’ve given up
on SPTI for the reason that SPTI is serialized in SCSIPORT, to the effect
that I will never see a queue. Am I right about that?

So I’m thinking an upper SCSI class filter instead, with a couple of
approaches. One would be to change the Inquiry data, so it doesn’t appear
to the system as a recognized device, and then add a class driver for the
new device type, which is nothing more than a front end to the diag app.
The second would be to create a named DO on the filter, and have the app
open that handle. The second way seems simpler, but less elegant, and opens
a potential BSOD if there is a recognized FS on the device under test, and
the user forgets to remove the volume before making changes to the media
that the fs driver doesn’t know about. So my inclination is to do it with a
custom device type in inquiry, with matching class driver. Anyone see any
holes in my logic? I won’t be surprised to find really big ones, though I
will certainly be grateful to the person who points them out.

Either way I go, I have to start with the filter. I’d prefer to buy one as
a starting point, but “Penny-wise, pound-foolish” is descriptive of my
operating environment right now. Having seen some discussion of SCSI upper
filters recently, I am trying to implement it the way Mark and PeterWie
suggested, which is to really attach as a lower filter to the PDOs for each
device on the SCSI bus. I’m looking at DeviceTree with Mark’s htsScsiView
filter loaded, and I can see where I need to plug into the stack. After
reading all the references to this I can find anywhere, including on the old
NTDEV archive, I believe I need to do this in
DispatchPnp->IRP_MN_QUERY_DEVICE_RELATIONS for
Irpstack->Parameters.QueryDeviceRelations.Type == BusRelations?. Am I
correct in this belief? I don’t get AddDevice calls for anything except the
SCSI bus FDO, which isn’t much use, of course.

What else do I need to know about this? If I’m inserting myself into the
device stack on IRP_MN_QUERY_DEVICE_RELATIONS, I need to take myself out on
IRP_MN_REMOVE, right? Any other considerations?

Thanks,

Phil

–
Philip D. Barila
Seagate Technology, LLC
(720) 684-1842

2

Phil,

A possible solutiion might be to think “outside the box”. If the old
chocolate syrup can don’t have enough syrup for chocolate milk, then pour
the milk into the can and shake shake shake … damn I love that commercial
… :slight_smile:

Given that drivers are nothing more than DLLs and that a minport is nothing
more than a DLL within a DLL, and over all code is code … could you not
hook the miniports entry points to process the SRBs the way you need to for
the diagnostics, but always chaining to the proper miniport functions at the
end of your processing? Given that you have control of the miniport code,
once back in the miniports DriverEntry routine, either hook the miniport
entry points with your “intermediate” entry points, or hook the IRP IoCtrl
calls that will lead to the mini-port entry points. Alternately yhe miniport
might need a back door through a special IoCtl to the miniport to do the
hooking, or you can chase down the FDO/PDO objects you need in the SCSIPORT
driver object. A little judicial “playing” with WinDbg will tell you where
the mini-port entry points are in the device extension. Since you are
dealing with diagnostics and I assume a special case, and not for commercial
release, you should have the lea-way to own whatever part of the code you
need to own.

As to the serialization of SPTI … you can also chase down the FDO of
SCSIPORT, back in the DrieveEntry routine, and then hang a DPC queue request
on that device object. The DPC will then call the SCSPORT DpcForIsr which
will lead to your CallEnableInterrupt callback.

Just a couple of non-standard suggestions for a problem that is
non-standard. I know the DPC suggestion will work, since I have done it. The
others I have wondered about, but never found any need to totally violate
SCSIPORT in that manner.

Gary G. Little
Have Computer, Will travel …
909-698-3191
909-551-2105

3

“Gary G. Little” wrote in message news:xxxxx@ntdev…
>
> Phil,
>
> A possible solutiion might be to think “outside the box”. If the old
> chocolate syrup can don’t have enough syrup for chocolate milk, then pour
> the milk into the can and shake shake shake … damn I love that
commercial
> … :slight_smile:

Done that, many times. Long before the marketing drones figured it out.
:slight_smile:

>
> Given that drivers are nothing more than DLLs and that a minport is
nothing
> more than a DLL within a DLL, and over all code is code … could you not
> hook the miniports entry points to process the SRBs the way you need to
for
> the diagnostics, but always chaining to the proper miniport functions at
the
> end of your processing? Given that you have control of the miniport code,
> once back in the miniports DriverEntry routine, either hook the miniport
> entry points with your “intermediate” entry points, or hook the IRP IoCtrl
> calls that will lead to the mini-port entry points. Alternately yhe
miniport
> might need a back door through a special IoCtl to the miniport to do the
> hooking, or you can chase down the FDO/PDO objects you need in the
SCSIPORT
> driver object. A little judicial “playing” with WinDbg will tell you where
> the mini-port entry points are in the device extension. Since you are
> dealing with diagnostics and I assume a special case, and not for
commercial
> release, you should have the lea-way to own whatever part of the code you
> need to own.

Where did I give the erroneous impression that I own the miniport? I don’t
own the miniport at all. If I owned the miniport, this would be far easier.
I did think about hooking the entry points of the miniport, but that means I
have to special-case every different adapter. No thanks. Of course,
without the miniport source, I have no guarantees that the miniport will
pass the arbitrary cdbs to the devices. Some may reject anything they don’t
understand if they arrive in StartIo as SRB_FUNCTION_EXECUTE_SCSI, but it’s
the same problem if I am hooking the miniport’s entry points directly, or
using a filter and a custom class driver. Ultimately, it’s the miniport who
decides just what gets to the hardware, but at least I’ll have a queue of
arbitrary length of cdbs the miniport is ignoring. :-z

So with that in mind, maybe it’s more clear why I favor the approach I’ve
chosen.

>
> As to the serialization of SPTI … you can also chase down the FDO of
> SCSIPORT, back in the DrieveEntry routine, and then hang a DPC queue
request
> on that device object. The DPC will then call the SCSPORT DpcForIsr which
> will lead to your CallEnableInterrupt callback.

Yes, if I had a miniport with Disable/EnableInterrupt pair. I don’t have
that.

>
> Just a couple of non-standard suggestions for a problem that is
> non-standard. I know the DPC suggestion will work, since I have done it.
The
> others I have wondered about, but never found any need to totally violate
> SCSIPORT in that manner.

Thanks, and any other wild ideas are appreciated, as well.

Phil
–
Philip D. Barila
Seagate Technology, LLC
(720) 684-1842

4

Phil,

Give me a call his afternoon and lets chat.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Phil Barila
Sent: Monday, October 07, 2002 8:07 AM
To: NT Developers Interest List
Subject: [ntdev] Re: SCSI filtering again

“Gary G. Little” wrote in message
news:xxxxx@ntdev…
>
> Phil,
>
> A possible solutiion might be to think “outside the box”. If the old
> chocolate syrup can don’t have enough syrup for chocolate milk, then
pour
> the milk into the can and shake shake shake … damn I love that
commercial
> … :slight_smile:

Done that, many times. Long before the marketing drones figured it out.
:slight_smile:

>
> Given that drivers are nothing more than DLLs and that a minport is
nothing
> more than a DLL within a DLL, and over all code is code … could you
not
> hook the miniports entry points to process the SRBs the way you need
to
for
> the diagnostics, but always chaining to the proper miniport functions
at
the
> end of your processing? Given that you have control of the miniport
code,
> once back in the miniports DriverEntry routine, either hook the
miniport
> entry points with your “intermediate” entry points, or hook the IRP
IoCtrl
> calls that will lead to the mini-port entry points. Alternately yhe
miniport
> might need a back door through a special IoCtl to the miniport to do
the
> hooking, or you can chase down the FDO/PDO objects you need in the
SCSIPORT
> driver object. A little judicial “playing” with WinDbg will tell you
where
> the mini-port entry points are in the device extension. Since you are
> dealing with diagnostics and I assume a special case, and not for
commercial
> release, you should have the lea-way to own whatever part of the code
you
> need to own.

Where did I give the erroneous impression that I own the miniport? I
don’t
own the miniport at all. If I owned the miniport, this would be far
easier.
I did think about hooking the entry points of the miniport, but that
means I
have to special-case every different adapter. No thanks. Of course,
without the miniport source, I have no guarantees that the miniport will
pass the arbitrary cdbs to the devices. Some may reject anything they
don’t
understand if they arrive in StartIo as SRB_FUNCTION_EXECUTE_SCSI, but
it’s
the same problem if I am hooking the miniport’s entry points directly,
or
using a filter and a custom class driver. Ultimately, it’s the miniport
who
decides just what gets to the hardware, but at least I’ll have a queue
of
arbitrary length of cdbs the miniport is ignoring. :-z

So with that in mind, maybe it’s more clear why I favor the approach
I’ve
chosen.

>
> As to the serialization of SPTI … you can also chase down the FDO of
> SCSIPORT, back in the DrieveEntry routine, and then hang a DPC queue
request
> on that device object. The DPC will then call the SCSPORT DpcForIsr
which
> will lead to your CallEnableInterrupt callback.

Yes, if I had a miniport with Disable/EnableInterrupt pair. I don’t
have
that.

>
> Just a couple of non-standard suggestions for a problem that is
> non-standard. I know the DPC suggestion will work, since I have done
it.
The
> others I have wondered about, but never found any need to totally
violate
> SCSIPORT in that manner.

Thanks, and any other wild ideas are appreciated, as well.

Phil
–
Philip D. Barila
Seagate Technology, LLC
(720) 684-1842

—
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%

5

:slight_smile:

Hey … you never know, my cranial infarctions might have been the big
winner.

Gary

6

“Gary G. Little” wrote in message news:xxxxx@ntdev…
>
> :slight_smile:
>
> Hey … you never know, my cranial infarctions might have been the big
> winner.
>
> Gary

It was a fine idea, except for needing the miniport code. :slight_smile:

–
Philip D. Barila
Seagate Technology, LLC
(720) 684-1842

7

Depending on how far you are allowed to color outside the lines … even
the mini-port would not be absolutely required. But … that kind of thing
takes time and is fragile in relation to future releases and service packs.

Gary G. Little
Have Computer, Will travel …
909-698-3191
909-551-2105

“Phil Barila” wrote in message
news:xxxxx@ntdev…
>
> “Gary G. Little” wrote in message news:xxxxx@ntdev…
> >
> > :slight_smile:
> >
> > Hey … you never know, my cranial infarctions might have been the big
> > winner.
> >
> > Gary
>
> It was a fine idea, except for needing the miniport code. :slight_smile:
>
> –
> Philip D. Barila
> Seagate Technology, LLC
> (720) 684-1842
>
>
>
>

8

“Gary G. Little” wrote in message news:xxxxx@ntdev…
>
> Depending on how far you are allowed to color outside the lines … even
> the mini-port would not be absolutely required. But … that kind of thing
> takes time and is fragile in relation to future releases and service
packs.

It all comes down to relying on the miniport to do what you want it to do,
or else writing your own, doesn’t it? Any way you slice it, since I don’t
own the miniport source, I am entirely at its mercy. So I can patch the
dispatch table in the miniport’s DO, or I can use the PnP system to do the
same thing in a fashion that is, more or less, blessed by the developers of
the OS, but ultimately it’s still the miniport’s HwStartIo routine that will
deliver or block the cdb I want to drop on the device, and there’s nothing I
can do about that, short of writing my own hardware driver. And since this
is supposed to be as hardware independent as I can make it, that’s
undesirable. If anyone has reason to disabuse me of this notion, I’d be
delighted to see your thoughts.

Phil

–
Philip D. Barila
Seagate Technology, LLC
(720) 684-1842