NAME

scsi_hba_iportmap_create, scsi_hba_iportmap_destroy, scsi_hba_iportmap_iport_add, scsi_hba_iportmap_iport_remove — create and manage an iportmap

SYNOPSIS

#include <sys/scsi/scsi.h>

int
scsi_hba_iportmap_create(dev_info_t *dip, int csync_usec, int settle_usec, scsi_hba_iportmap_t **iportmapout);

void
scsi_hba_iportmap_destroy(scsi_hba_iportmap_t *iportmap);

int
scsi_hba_iportmap_iport_add(scsi_hba_iportmap_t *iportmap, char *ua, void *priv);

int
scsi_hba_iportmap_iport_remove(scsi_hba_iportmap_t *iportmap, char *ua);

INTERFACE LEVEL

Evolving - This interface is still evolving in illumos. API and ABI stability is not guaranteed.

PARAMETERS

dip: Pointer to dev_info structure.
csync_usec: A time in microseconds.
settle_usec: A time in microseconds.
iportmap: An allocated iportmap.
iportmapout: Pointer where the iportmap is stored.
ua: A character string that represents a unit address for an iport.
priv: Drivers should pass NULL for this field.

DESCRIPTION

The scsi_hba_iportmap_create() and scsi_hba_iportmap_destroy() functions are used by HBA drivers to create and destroy an iportmap. For more information on an iportmap and its purpose, see iportmap(9).

The csync_usec and settle_usec are both times measured in microseconds that control two different properties of the iportmap and how it behaves. The value in settle_usec indicates the amount of time that the system should wait to quiesce all changes and consider the resulting system stable. Changes will not be reported until after settle_usec have passed. csync_usec indicates how much time needs to elapse after creation before an initial enumeration has been completed.

The dev_info structure passed into dip is usually the HBA driver's dev_info structure.

When the scsi_hba_iportmap_iport() function returns, iportmapout will be populated with a pointer to an iportmap that can be used to add and remove iports.

To destroy the iportmap, drivers should use the scsi_hba_iportmap_destroy() function. As part of destroying the iportmap, all associated iports will be detached from the system by having the driver's detach(9E) entry point called.

When the driver needs to add an iport to the system, generally in response to a hotplug event, then the driver should call the scsi_hba_iportmap_iport_add() function. The value of ua should be a character string that uniquely identifies the device. If the driver is using a phymap, then this unit address should be the same one as the phymap's callback provided. Otherwise, the driver sets ua to a unique string which is generally the iport's WWN.

When the corresponding iport needs to be removed, then the driver should call the scsi_hba_iportmap_remove() function. The iport to remove is indicated by the ua argument, which should match the value passed into the scsi_hba_iportmap_add() function.

CONTEXT

The scsi_hba_iportmap_create() function is generally called during a driver's attach(9E) entry point.

The scsi_hba_iportmap_destroy() function is generally called during a driver's detach(9E) entry point.

The scsi_hba_iportmap_iport_add() and scsi_hba_iportmap_iport_remove() functions should be called from kernel context.

RETURN VALUES

Upon successful completion, the scsi_hba_iportmap_create(), scsi_hba_iportmap_iport_add(), and scsi_hba_iportmap_iport_remove() functions return DDI_SUCCESS. Otherwise, DDI_FAILURE is returned.