up to an administrative entity controlling the vport. For example,
if vports are to be associated with virtual machines, a XEN mgmt
utility would be responsible for creating wwpn/wwnn's for the vport,
- using it's own naming authority and OUI. (Note: it already does this
+ using its own naming authority and OUI. (Note: it already does this
for virtual MAC addresses).
with rports and scsi target objects underneath it. Currently the FC
transport creates the vport object and places it under the scsi_host
object corresponding to the physical adapter. The LLDD will allocate
- a new scsi_host for the vport and link it's object under the vport.
+ a new scsi_host for the vport and link its object under the vport.
The remainder of the tree under the vports scsi_host is the same
as the non-NPIV case. The transport is written currently to easily
allow the parent of the vport to be something other than the scsi_host.
Vport support by LLDD:
The LLDD indicates support for vports by supplying a vport_create()
- function in the transport template. The presense of this function will
+ function in the transport template. The presence of this function will
cause the creation of the new attributes on the fc_host. As part of
the physical port completing its initialization relative to the
transport, it should set the max_npiv_vports attribute to indicate the