SCSI_HBA_IPORTMAP_CREATE(9F) Kernel Functions for Drivers

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.

SEE ALSO

iport(9), iportmap(9), attach(9E), detach(9E)

OmniOS April 18, 2017 OmniOS