w2k port filter driver SRB's

Hi,

I am writing a port filter driver to only allow certain disks to be
accessible.

When SRB_FUNCTION_CLAIM_DEVICE is called for a disk that should not be
accessible the request is failed.
Then when I want the disk to be accessible I need to tell the disk class
driver to try to reclaim the device again
Any ideas how to do this?

Do all IOCTLS go through SRB’s at the port filter driver level which would
mean they would go through IRP_MJ_SCSI = IRP_MJ_INTERNAL_DEVICE_CONTROL?

Also, for a port filter driver should I be attaching as a lower filter to
the disk class driver?
I tried attaching as an upper filter to the SCSI adapter but then I
received no SRB’s.

Thanks

Mike

>

I am writing a port filter driver to only allow certain disks to be
accessible.

When SRB_FUNCTION_CLAIM_DEVICE is called for a disk that
should not be
accessible the request is failed.
Then when I want the disk to be accessible I need to tell the
disk class
driver to try to reclaim the device again
Any ideas how to do this?

I’m not sure that this approach is going to work. Disk class and scsiport
are both PnP drivers. You could convince scsiport to rescan the scsi bus,
but it already found the device objects that you rejected the claim for, so
nothing new has happened there. Likewise, since scsiport isn’t reporting
anything new, pnp isn’t going to ask the disk class driver to create FDOs
for any new device objects of type DISK.

Do all IOCTLS go through SRB’s at the port filter driver
level which would
mean they would go through IRP_MJ_SCSI =
IRP_MJ_INTERNAL_DEVICE_CONTROL?

Also, for a port filter driver should I be attaching as a
lower filter to
the disk class driver?
I tried attaching as an upper filter to the SCSI adapter but then I
received no SRB’s.

If you filter as a disk class lower filter driver then you are not a
scsiport filter driver, you are a disk class lower filter driver.

The reason you didn’t see any SRBs when you tried to be an upper filter
driver for scsiport devices is that you were an upper filter driver for a
BUS FDO. You were not filtering the PDO’s created by scsiport for each
target/lun. To do that you would have to write a PDO filter driver and
unfortunately microsoft has not seen fit to document how one should go about
doing that.

This might get you pointed in the right direction:

Your scsiport FDO filter driver could look at the results returned by a
IRP_MN_QUERY_DEVICE_RELATIONS type BusRelations and remove the PDOs that
correspond to the devices that you do not want disk to deal with. When you
wanted to change the configuration you could invalidate the BUS FDO and
force a re-enumeration from PnP. This would result in another
IRP_MN_QUERY_DEVICE_RELATIONS type BusRelations and you could now allow a
formerly hidden PDO to appear.

Thank you for the good explanation Mark

In NT 4 an IOCTL_STORAGE_FIND_NEW_DEVICES works to try and reclaim the
device

But in W2k the DDK says
“This IOCTL is obsolete in the Plug and Play environment. Plug and Play
class drivers handle this request by calling
IoSynchronousInvalidateDeviceRelations with the device relations type
BusRelations. If a new device is found, the class driver’s AddDevice
routine will be called.”

I have tried calling IoSynchronousInvalidateDeviceRelations with
BusRelations but the function can’t be found in the DDK so I used
IoInvalidateDeviceRelations with BusRelations which doesn’t seem to be
synchronous from a driver that is an upper filter to the disk class
driver.

Has anyone successfully used IoSynchronousInvalidateDeviceRelations or is
that an error in the DDK docs?

I have also tried IoInvalidateDeviceRelations with TargetDevice relations
which doesn’t seem to do much at all
and IoInvalidateDeviceState
It doesn’t seem to reclaim which makes sense because there both PnP drivers
like you explained Mark.
When the disk is unassigned there is no link for \Device\HarddiskX or
??\PhysicalDriveX so how would I go about sending a request to it?

Your scsiport FDO filter driver could look at the results returned by a
IRP_MN_QUERY_DEVICE_RELATIONS type BusRelations and remove the PDOs that
correspond to the devices that you do not want disk to deal with. When you
wanted to change the configuration you could invalidate the BUS FDO and
force a re-enumeration from PnP. This would result in another
IRP_MN_QUERY_DEVICE_RELATIONS type BusRelations and you could now allow a
formerly hidden PDO to appear.

At AddDevice time I am given the PDO. I store that in the devExt so after
the claim fails can I just do an IoDeleteDevice or how do I go about
deleting the PDO?

I am trying to assign and unassign certain disks.
Is there a way to do this without an upper and lower filter to the disk
class driver?

Also diskperf in NT attaches to disk partitions but diskperf in W2k does
not so is there a way to attach a filter driver to disk partitions?

Thanks again for the help,

Mike

On 09/08/00, ““Roddy, Mark” ” wrote:
> >
> > I am writing a port filter driver to only allow certain disks to be
> > accessible.
> >
> > When SRB_FUNCTION_CLAIM_DEVICE is called for a disk that
> > should not be
> > accessible the request is failed.
> > Then when I want the disk to be accessible I need to tell the
> > disk class
> > driver to try to reclaim the device again
> > Any ideas how to do this?
> >
>
> I’m not sure that this approach is going to work. Disk class and scsiport
> are both PnP drivers. You could convince scsiport to rescan the scsi bus,
> but it already found the device objects that you rejected the claim for, so
> nothing new has happened there. Likewise, since scsiport isn’t reporting
> anything new, pnp isn’t going to ask the disk class driver to create FDOs
> for any new device objects of type DISK.
>
> > Do all IOCTLS go through SRB’s at the port filter driver
> > level which would
> > mean they would go through IRP_MJ_SCSI =
> > IRP_MJ_INTERNAL_DEVICE_CONTROL?
> >
> > Also, for a port filter driver should I be attaching as a
> > lower filter to
> > the disk class driver?
> > I tried attaching as an upper filter to the SCSI adapter but then I
> > received no SRB’s.
> >
>
> If you filter as a disk class lower filter driver then you are not a
> scsiport filter driver, you are a disk class lower filter driver.
>
> The reason you didn’t see any SRBs when you tried to be an upper filter
> driver for scsiport devices is that you were an upper filter driver for a
> BUS FDO. You were not filtering the PDO’s created by scsiport for each
> target/lun. To do that you would have to write a PDO filter driver and
> unfortunately microsoft has not seen fit to document how one should go about
> doing that.
>
> This might get you pointed in the right direction:
>

> Thank you for the good explanation Mark

In NT 4 an IOCTL_STORAGE_FIND_NEW_DEVICES works to try and reclaim the
device

The ScsiDisk driver (source from NT4 DDK) scans the machine for disks in
DriverEntry ONLY and there are no ways to force the rescan.

Max

If you run WINDISK on an NT4 machine it will immediately force a new scan of
all buses.

Regards,

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

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Monday, September 18, 2000 10:42 AM
To: NT Developers Interest List
Subject: [ntdev] RE: w2k port filter driver SRB’s

Thank you for the good explanation Mark

In NT 4 an IOCTL_STORAGE_FIND_NEW_DEVICES works to try and reclaim the
device

The ScsiDisk driver (source from NT4 DDK) scans the machine for disks in
DriverEntry ONLY and there are no ways to force the rescan.

> If you run WINDISK on an NT4 machine it will immediately force a new scan
of

all buses.

Sorry, I have overlooked the place in ScsiDisk code where they call their
DriverEntry routine
from within the already initialized driver_ in order to
rescan buses!
Great idea. Like calling main() from within a user-mode C program :slight_smile:

Max