PnP for Iscsi miniport

NTFSD
1

Hi there ,

Does anybody know if IoAttachDeviceToDeviceStack() is idempotent i.e. if
called twice yields the same result
(returned PDO) ?

I am writing an HBA Iscsi miniport driver for win2000. It should be PnP
compatible. I notice that scsiPort driver (actuall a library
that is statically linked with the miniport) PnP AddDevice routine
(DriverObject->DriverExtension->AddDevice) is not NULL
and I assume it is a true pointer to the original ScsiPort AddEvice routine
. I intend to wrap the original AddDevice with my
AddDevice to keep its functionality +add another call to
IoAttachDeviceToDeviceStack() to get the PDO to which I should pass
all (or most) of the PnP IRPs (the miniport handles) as mandated by MSDN .
Or maybe the PDO passed to AddDevice is already the PDO to pass PnP IRPs to
in case of scsiport since there is no drivers
in between ?!

dubi

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

2

Probably wrong forum for the question? Yours is a device driver
question.

  1. No to idempotency: calling IoAttachDevice* twice will result in 2
    attachments.
  2. You shouldn’t use IoAttachDevice* to get top of stack, that’s
    IoGetAttachedDevice
  3. Finally, SCSIPORT handles PnP all by itself - if you are writing a
    miniport, you do not have an AddDevice entry point. Replacing the
    ScsiPort one is not recommended. It’s not clear why you want to do this.

-----Original Message-----
From: dubi@il.ibm.com [mailto:dubi@il.ibm.com]
Sent: Sunday, April 15, 2001 2:29 PM
To: File Systems Developers
Subject: [ntfsd] PnP for Iscsi miniport

Hi there ,

Does anybody know if IoAttachDeviceToDeviceStack() is idempotent i.e.
if called twice yields the same result (returned PDO) ?

I am writing an HBA Iscsi miniport driver for win2000. It should be PnP
compatible. I notice that scsiPort driver (actuall a library that is
statically linked with the miniport) PnP AddDevice routine
(DriverObject->DriverExtension->AddDevice) is not NULL
and I assume it is a true pointer to the original ScsiPort AddEvice
routine . I intend to wrap the original AddDevice with my AddDevice to
keep its functionality +add another call to
IoAttachDeviceToDeviceStack() to get the PDO to which I should pass all
(or most) of the PnP IRPs (the miniport handles) as mandated by MSDN .
Or maybe the PDO passed to AddDevice is already the PDO to pass PnP IRPs
to in case of scsiport since there is no drivers in between ?!

dubi

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

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

3

thanks,

Let me refrase my question :

  1. If scsiport under Win2000 generally handles PnP is there any need for
    the miniport to handle any of
    the PnP Irps coming down by redirecting IRP_MJ_PNP dispatch to its own
    , handling those it
    needs (HW related like QUERY_ID ,QUERY _RESOURCE_REQ etc.) and call the
    original scsiport’s for all the
    rest ?
    If so what happens to PnP Irps that have to be passed on to the PDO by
    the miniport if any ?
    if addDevice is of scsiport the miniport does not know the PDO ! ( and
    PDO is either that received into addDevice
    or the result of IoAttachDeviceToDeviceStack() ) .

  2. In case I work for a while without a real HBA , should I do something at
    the miniport to get a corrcet PnP behaviour?

  3. does the scsiport handle IRP_MN_STOP_DEVICE , START_DEVICE and
    translate then to srb functions
    coming down to the miniport like SRB_FUNCTION_FLUSH ,
    SRB_FUNCTION_SHUTDOWN ,
    SRB_FUNCTION_RESET_BUS?

I will appreciate your answer ,
Zvi

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