Hi Som,
I guess you uses "scsi" as class when you add_drv.
And I think you name your iSCSI target device by "target,lun" and
target is a short digital # and not a "iqn" name, right?
The easiest way is: NOT use "-c scsi" when you add_drv and make
sure the driver_class of your driver is not "scsi" in /etc/driver_classes
which will prevent ".conf" nodes from showing up.
About merge ".conf" node, please implement tran_tgt_init() routine
to check for .conf nodes. If it is a .conf node, merge it to the
node you have allocated and return failure. It's roughly like:
if (ndi_dev_is_persistent_node(tgt_dip) == 0) {
(void) ndi_merge_node(tgt_dip, scsi_name_child);
ddi_set_name_addr(tgt_dip, NULL);
return (DDI_FAILURE);
}
The function scsi_name_child should be something like:
int
scsi_name_child(dev_info_t *dip, char *name, int namelen)
{
lookup taget and lun properties
if either property doesn't exist
return (DDI_FAILURE);
(void) snprintf(name, namelen, "%d,%d", target, lun);
return (DDI_SUCCESS);
}
Cheers
Javen
Somnath kotur wrote:
>Hi Javen,
> Sorry for the previous mail ,some keystroke
>combination accidentally sent it out while i was in
>between typing
> I think the root cause for this problem
>might be something else which is that even i do a
>succesful login to a target and my ndi_devi_online for
>the corresponding LUN behind the tgt succeeds ,the
>prtconf output looks as below:
>
>'pci<my vendorid>,<subsysid>,instance# 0
> disk <some instance number>
> sd, instance #1 (driver not attached)
> st, instance #0 (driver not attached)
> ses, instance #0 (driver not attached)
>'
>
>With this,when i run the 'format' utility i am able to
>see the LUN ,similiarly when i do a logout ,the first
>line in the prtconf output disappears
>
>'pci<my vendorid>,<subsysid>,instance# 0
> sd, instance #1 (no driver attached)
> st, instance #1 (no driver attached)
> ses, instance #0 (driver not attached)
>'
>
>So im not sure if this is right and how to get rid of
>or merge the node that my driver creates through
>ndi_devi_alloc (for the LUN) and the above 'sd' node
>that i guess is being created via sd.conf entries
>
>I remember you mentioning about ndi_merge_node but i
>could not find much about the semantics of the API and
>usage? None of the other SCSI HBA drivers including
>solaris's own iscsi initiator seem to invoking that
>call
>Any ideas
>
>Thanks
>Som
>
>
>
>
>
>
>
>
>
>--- Javen Wu <[EMAIL PROTECTED]> wrote:
>
>
>
>>Hi Som,
>>
>>I can understand the word "attached" in your email
>>in two ways.
>>1. "attached" means the *driver* attachs with the
>>device.
>>2. "attached" means the device hook up with the
>>iscsi initiator port.
>>
>>If you mean #1, I think the answer is "No" or
>>"impossible" in my mind.
>>If you mean #2, I think the answer is "Yes" and
>>"possible" but need
>>extra work.
>>
>>I assume you mean #2, let me explain how to reach
>>your aim to unload your
>>iscsi driver with the target hooked up with your
>>initiator port.
>>
>> From driver side,
>>================
>>you need implement tran_bus_unconfig() routine in
>>your HBA driver.
>>For BUS_UNCONFIG_ALL, you need call
>>ndi_devi_offline() manually in
>>your tran_bus_unconfig() for all attached target
>>devices with
>>NDI_DEVI_REMOVE argument.
>>
>> From user land,
>>==============
>>you need a utility to trigger the
>>tran_bus_unconfig(), there are
>>two options,
>>1. implement cfgadm(1M) plugin for your HBA driver
>>so that you
>>can borrow "cfgadm -c unconfigure controller" to
>>trigger bus
>>unconfigure all.
>>2. implement another utility by yourself and call
>>scsi standard
>>ioctl() with cmd "DEVCTL_BUS_UNCONFIGURE". (please
>>refer to
>>scsi_hba_ioctl()).
>>
>>Maybe other guys have better idea, above is just
>>what I thought.;)
>>
>>Hope it helps.
>>
>>Cheers
>>Javen
>>
>>
>>Somnath kotur wrote:
>>
>>
>>
>>>Hi Javen,
>>> Thanks for the info. Well my iSCSI driver
>>>requires that i be able to rem_drv my driver with
>>>tgts/luns attached ,i.e im wondering if the
>>>
>>>
>>framework
>>
>>
>>>internally provides options for the HBA driver to
>>>detach its luns, i think i did see a print
>>>
>>>
>>indicating
>>
>>
>>>that tran_lun_reset_notify was called when i did
>>>attempt to do it..so thats what im intersted to
>>>
>>>
>>know
>>
>>
>>>..is there a sequence to the rem_drv if/when
>>>LUNs/Targets are attached to the SCSI HBA driver so
>>>that i get a chance to remove all the child
>>>
>>>
>>instances
>>
>>
>>>of the driver from the device tree?
>>>
>>>Thanks
>>>Som
>>>
>>>--- Javen Wu <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>
>>>
>>>>Hi Som,
>>>>
>>>>There are two possible scenarios which you can
>>>>unload your SCSI HBA
>>>>driver without reboot.
>>>>1. No any child of the HBA driver instance in the
>>>>device tree.
>>>>2. If you boot system is not from a SCSI disk and
>>>>you can try to unload
>>>>sd(7D) driver by "rem_drv sd" without any risk,
>>>>
>>>>
>>you
>>
>>
>>>>can unload your SCSI
>>>>HBA driver by rem_drv(1M).
>>>>
>>>>Thanks
>>>>Javen
>>>>
>>>>
>>>>Garrett D'Amore wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>Somnath kotur wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Javen ,
>>>>>> Is it actually possible to rem_drv my
>>>>>>
>>>>>>
>>>>>>
>>>>SCSI
>>>>
>>>>
>>>>
>>>>>>HBA driver ? I read this note below in one of
>>>>>>
>>>>>>
>>the
>>
>>
>>>>>>driver docs ,not sure if it is dated
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>******************************************************
>>
>>
>>>>>>Removing the Driver
>>>>>>
>>>>>>To remove a driver from the system, use
>>>>>>
>>>>>>
>>>>>>
>>>>rem_drv(1M),
>>>>
>>>>
>>>>
>>>>>>then delete the driver module and configuration
>>>>>>
>>>>>>
>>>>>>
>>>>file
>>>>
>>>>
>>>>
>>>>>>from the module path. The driver cannot be used
>>>>>
>>>>>
>>>>again
>>>>
>>>>
>>>>
>>>>>>until it is reinstalled with add_drv(1M).
>>>>>>
>>>>>>
>>>>>>
>>>>Removing a
>>>>
>>>>
>>>>
>>>>>>SCSI HBA driver will require a reboot to take
>>>>>>
>>>>>>
>>>>>>
>>>>effect.
>>>>
>>>>
>>>>
>>******************************************************
>>
>>
>>>>>>If its actually possible now, what are the
>>>>>>
>>>>>>
>>entry
>>
>>
>>>>>>points that it would hit and i would need to
>>>>>>
>>>>>>
>>take
>>
>>
>>>>care
>>>>
>>>>
>>>>
>>>>>>of in my SCSI HBA driver particularly if i have
>>>>>>LUNs/targets attached?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>rem_drv works, but for SCSI drivers its actions
>>>>>
>>>>>
>>>>>
>>>>are not likely to take
>>>>
>>>>
>>>>
>>>>>effect until the next boot.
>>>>>
>>>>>The problem is that if you have any target nodes
>>>>>
>>>>>
>>>>>
>>>>still attached, then
>>>>
>>>>
>>>>
>>>>>the framework will refuse to detach your node.
>>>>>
>>>>>
>>If
>>
>>
>>>>your bus is
>>>>
>>>>
>>>>
>>>>>hotpluggable, you could try hot-unplugging each
>>>>>
>>>>>
>>of
>>
>>
>>>>the targets (making
>>>>
>>>>
>>>>
>>>>>sure that they are not in use first!), then the
>>>>>
>>>>>
>>>>>
>>>>framework will see
>>>>
>>>>
>>>>
>>>>>that you have no dependencies in the device tree
>>>>>
>>>>>
>>>>>
>>>>(providing your
>>>>
>>>>
>>>>
>>>>>driver actually does ndi_devi_offline for devices
>>>>>
>>>>>
>>>>>
>>>>that were hot removed).
>>>>
>>>>
>>>>
>>>>>In that case, your driver will see its detach(9e)
>>>>>
>>>>>
>>>>>
>>>>entry point called
>>>>
>>>>
>>>>
>>>>>with cmd == DDI_DETACH. I do not believe that
>>>>>
>>>>>
>>>>>
>>>>you'll see any other
>>>>
>>>>
>>>>
>>>>>entry points called during the rem_drv.
>>>>>
>>>>> -- Garrett
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Thanks Som
>>>>>>
>>>>>>
>>>>>>
>=== message truncated ===
>
>
>
>
> ____________________________________________________________________________________
>Never miss a thing. Make Yahoo your home page.
>http://www.yahoo.com/r/hs
>
>
_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
