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:
>
