Tribblix: manual page: scsi_hba_iportmap

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.