OS-6175 fix manual pages for newer mdoc lint

Reviewed by: Jerry Jelinek <jerry.jelinek@joyent.com>
Approved by: Jerry Jelinek <jerry.jelinek@joyent.com>

26 files changed, 917 insertions, 666 deletions

diff --git a/usr/src/man/man1/ctfdiff.1 b/usr/src/man/man1/ctfdiff.1
index 1934c64c52..c0e59436fa 100644
--- a/usr/src/man/man1/ctfdiff.1
+++ b/usr/src/man/man1/ctfdiff.1
@@ -55,10 +55,12 @@ and
 .Lp
 Two
 .Sy labels
-are considered the same, if they have the same name. Two
+are considered the same, if they have the same name.
+Two
 .Sy objects
 are considered the same if they have the same name and the type of the
-object is the same. Two
+object is the same.
+Two
 .Sy functions
 are considered the same if they have the same, the same return type, the
 same number of arguments, and the types of their arguments are the same.
@@ -66,16 +68,18 @@ same number of arguments, and the types of their arguments are the same.
 Two
 .Sy types
 are considered the same if they have the same, they represent the same
-kind of thing, and the contents of the type are the same. This varies
-for each specific kind, for example, two structs are the same if they
-have the same members whose types, offsets, and names are all the same.
-For more information on the specifics for what we look at for each kind
-of type, and the kinds themselves, see the information we use to encode
-them in
-.Xr ctf 4 . If the option
+kind of thing, and the contents of the type are the same.
+This varies for each specific kind, for example, two structs are the
+same if they have the same members whose types, offsets, and names are
+all the same.
+For more information on the specifics for what we look at
+for each kind of type, and the kinds themselves, see the information we
+use to encode them in
+.Xr ctf 4 .
+If the option
 .Fl I
-is specified, then the names of basic integer types are ignored. For an
-example of where this makes sense, see
+is specified, then the names of basic integer types are ignored.
+For an example of where this makes sense, see
 .Sy Example 4 .
 .Lp
 If the
@@ -119,14 +123,15 @@ be specified and can be repeated multiple times.
 .Ed
 .It Fl I
 .Bd -filled -compact
-Ignore the names of integral types. This option is useful when comparing
-types between two
+Ignore the names of integral types.
+This option is useful when comparing types between two
 .Sy CTF
-containers that have different programming models. In this case, when
-comparing integers, the name of the type is not considered. This means
-that the ILP32 type long which is a 32-bit wide signed integer is the
-same as the LP64 type int which is a 32-bit wide signed integer, even
-though they have different names.
+containers that have different programming models.
+In this case, when comparing integers, the name of the type is not
+considered.
+This means that the ILP32 type long which is a 32-bit wide signed
+integer is the same as the LP64 type int which is a 32-bit wide signed
+integer, even though they have different names.
 .Ed
 .It Fl l
 .Bd -filled -compact
@@ -146,7 +151,8 @@ Diff type information for
 When diffing type information for
 .Sy objects ,
 only compare if the object is name
-.Em object . This option requires
+.Em object .
+This option requires
 .Fl o
 to be specified and can be repeated multiple times.
 .Ed
@@ -160,7 +166,8 @@ is
 .Em parent1 .
 This option is required if
 .Em file1
-has been uniquified. For more information on uniquification, see
+has been uniquified.
+For more information on uniquification, see
 .Xr ctf 4 .
 .Ed
 .It Fl P Ar parent2
@@ -172,12 +179,14 @@ container inside of
 .Em parent2 .
 This option is required if
 .Em file1
-has been uniquified. For more information on uniquification, see
+has been uniquified.
+For more information on uniquification, see
 .Xr ctf 4 .
 .Ed
 .It Fl q
 .Bd -filled -compact
-Enables quiet mode. Standard output from the diff will not be emitted.
+Enables quiet mode.
+Standard output from the diff will not be emitted.
 However, diagnostics messages will still be emitted to standard error.
 .Ed
 .It Fl t
@@ -229,7 +238,7 @@ and
 .It Sy 2
 .D1 Invalid command line options were specified.
 .It Sy 3
-.D1 A fatal error occured.
+.D1 A fatal error occurred.
 .El
 .Sh EXAMPLES
 .Sy Example 1
@@ -310,7 +319,8 @@ Diffing Types to Find Differences Between Different Data Models.
 .Lp
 This example looks for differences between structures used in an ioctl
 that the kernel wants to be bitness neutral by comparing a 32-bit and
-64-bit library that consumes it. In this example, we'll use the library
+64-bit library that consumes it.
+In this example, we'll use the library
 .Sy libvnd.so.1
 and the types
 .Sy vnd_ioc_attach_t ,
diff --git a/usr/src/man/man1/ctfdump.1 b/usr/src/man/man1/ctfdump.1
index a8c2d978ae..eb0fd10165 100644
--- a/usr/src/man/man1/ctfdump.1
+++ b/usr/src/man/man1/ctfdump.1
@@ -58,10 +58,11 @@ container.
 .Nm
 can also be used to dump out the raw
 .Sy CTF
-data and send it to another file. When writing out data, it always
-ensures that the
+data and send it to another file.
+When writing out data, it always ensures that the
 .Sy CTF
-data is decompressed. In this form, the
+data is decompressed.
+In this form, the
 .Sy CTF
 data can be inspected using
 .Nm
@@ -70,10 +71,11 @@ and other tools such as
 .Lp
 When no options are specified,
 .Nm
-displays all information. However, when the
+displays all information.
+However, when the
 .Fl u
 option is used, then no information is displayed by default, unless
-requested through the the appropriate option.
+requested through the appropriate option.
 .Sh OPTIONS
 The following options are supported:
 .Bl -hang -width Ds
@@ -101,7 +103,8 @@ labels associated with the file.
 .Bd -filled -compact
 Use the type information in
 .Em parent
-to supplement output. This is useful when a
+to supplement output.
+This is useful when a
 .Nm CTF
 container has been
 .Sy uniquified
@@ -147,23 +150,27 @@ When the
 utility is executed with its default options, it prints out a textual
 representation of the
 .Sy CTF
-information. Note, the output format of
+information.
+Note, the output format of
 .Nm
 is subject to change at any time and should not be relied upon as a
 stable format to be used for parsing.
 .Ss CTF Header
 This section describes the values in the
 .Sy CTF
-header. Each line in the section describes the value of one of the
-members of the header. For more information on the meaning and
-interpretation of these members, see
+header.
+Each line in the section describes the value of one of the
+members of the header.
+For more information on the meaning and interpretation of these members,
+see
 .Xr ctf 4 .
 .Ss Label Table
 This section describes information about the labels present in the
 .Sy CTF
-information. Each entry in this section, if present, starts with a
-number and is followed by a string. An example entry in the label
-section might look like:
+information.
+Each entry in this section, if present, starts with a
+number and is followed by a string.
+An example entry in the label section might look like:
 .Bd -literal
 \&...
    2270 joyent_20151001T070028Z
@@ -172,12 +179,14 @@ section might look like:
 .Pp
 The number,
 .Em 2270 ,
-represents the last type that the label applies to. The string,
+represents the last type that the label applies to.
+The string,
 .Em joyent_20151001T070028Z ,
-is the name of the label. In this case, if there were no other labels,
+is the name of the label.
+In this case, if there were no other labels,
 it would indicate that the label applied to all types up to, and
-including, the type number 2270. For more information
-on how labels are used with
+including, the type number 2270.
+For more information on how labels are used with
 .Sy CTF
 information, see the section
 .Em The Label Section
@@ -185,10 +194,12 @@ in
 .Xr ctf 4 .
 .Ss Data Objects
 This section describes the type information relating to data objects
-from the symbol table. An entry for a data object consists of four
-columns. The first column is just a monotonic ID. The second number is
-the type id of the object. The third column is the name of the symbol
-and the fourth column is the corresponding index from the symbol table.
+from the symbol table.
+An entry for a data object consists of four columns.
+The first column is just a monotonic ID.
+The second number is the type id of the object.
+The third column is the name of the symbol and the fourth column is the
+corresponding index from the symbol table.
 .Pp
 Take for example, the following couple of entries:
 .Bd -literal
@@ -202,18 +213,21 @@ Take for example, the following couple of entries:
 \&...
 .Ed
 .Pp
-Let's take the first entry in the list above. The symbol is named
+Let's take the first entry in the list above.
+The symbol is named
 .Sy hz .
 It is the first data object, as indicated by the number zero in
-brackets. It has a type id of 13 and in this case, it has a symbol table
-index of 48.
+brackets.
+It has a type id of 13 and in this case, it has a symbol table index of
+48.
 .Ss Functions
-This section describes the type information for functions. For each
-function present in the symbol table with type information, the
+This section describes the type information for functions.
+For each function present in the symbol table with type information, the
 function's entry into the function section, the function's name, the
 function's symbol table index, the function's return type, and the types
-of the function's arguments are printed. If a function is a variadic
-function, then the variadic argument is printed as the string
+of the function's arguments are printed.
+If a function is a variadic function, then the variadic argument is
+printed as the string
 .Sy '...' .
 .Pp
 Take for example, the following couple of entries:
@@ -228,40 +242,49 @@ Take for example, the following couple of entries:
 .Ed
 .Pp
 The first column is the function's entry number in the function type
-information section. It is enclosed in brackets. The next column is the
-function's name and it is followed in parenthesis by the its index in the
-symbol table. The following portions of this entry describe the return
+information section.
+It is enclosed in brackets.
+The next column is the function's name and it is followed in parenthesis
+by the its index in the
+symbol table.
+The following portions of this entry describe the return
 type and then all of the arguments, in positional order.
 .Ss Types
 The types section gives information about each type in the
 .Sy CTF
-container. Each entry begins with its type identifier. The type
-identifier may either be in square brackets or in angle brackets. If the
-type identifier is enclosed in angle brackets, then that represents that
-it is a root type or top-level type. If it is square brackets, then it
-is not. For more information on root types, see
+container.
+Each entry begins with its type identifier.
+The type identifier may either be in square brackets or in angle
+brackets.
+If the type identifier is enclosed in angle brackets, then that
+represents that it is a root type or top-level type.
+If it is square brackets, then it is not.
+For more information on root types, see
 .Xr ctf 4 .
 .Pp
-Next, the type will have its name and kind. If it is an array, it will
-be followed with a subscript that describes the number of entries in the
-array. If it is a pointer, it will followed by the
+Next, the type will have its name and kind.
+If it is an array, it will be followed with a subscript that describes
+the number of entries in the array.
+If it is a pointer, it will followed by the
 .Sy *
-symbol to indicate that it is a pointer. If the type has the
+symbol to indicate that it is a pointer.
+If the type has the
 .Sy const ,
 .Sy volatile ,
 .Sy typedef ,
 or
 .Sy restrict
-keyword applied to it, that will precede the name. All of these
-reference types, including pointer, will then be followed with an
-example of the type that they refer to.
+keyword applied to it, that will precede the name.
+All of these reference types, including pointer, will then be followed
+with an example of the type that they refer to.
 .Pp
 Types which are an integral or floating point value will be followed by
 information about their encoding and the number of bits represented in
 the type.
 .Pp
 Arrays will be followed by two different entries, the contents and
-index. The contents member contains the type id of the array's contents
+index.
+The contents member contains the type id of the array's contents
 and the index member describes a type which can represent the array's
 index.
 .Pp
@@ -269,10 +292,10 @@ Structures and unions will be preceded with the corresponding C keyword,
 .Sy struct
 or
 .Sy union .
-After that, the size in bytes of the structure will be indicated. ON
-each subsequent line, a single member will be listed. That line will
-contain the member's name, it's type identifier, and the offset into the
-structure that it can be found in, in bits.
+After that, the size in bytes of the structure will be indicated.
+ON each subsequent line, a single member will be listed.
+That line will contain the member's name, it's type identifier, and the
+offset into the structure that it can be found in, in bits.
 .Pp
 The following show examples of type information for all of these
 different types:
@@ -304,9 +327,12 @@ different types:
 .Ss String Table
 This section describes all of the strings that are present in the
 .Sy CTF
-container. Each line represents an entry in the string table. First the
-byte offset into the string table is shown in brackets and then the
-string's value is displayed. Note the following examples:
+container.
+Each line represents an entry in the string table.
+First the byte offset into the string table is shown in brackets and
+then the
+string's value is displayed.
+Note the following examples:
 .Bd -literal
   [0] \0
   [1] joyent_20151001T070028Z
@@ -317,15 +343,16 @@ string's value is displayed. Note the following examples:
 .Ss Statistics
 This section contains miscellaneous statistics about the
 .Sy CTF
-data present. Each line contains a single statistic. A brief explanation
-of the statistic is placed first, followed by an equals sign, and then
-finally the value.
+data present.
+Each line contains a single statistic.
+A brief explanation of the statistic is placed first, followed by an
+equals sign, and then finally the value.
 .Sh EXIT STATUS
 .Bl -inset
 .It Sy 0
 .Dl Execution completed successfully.
 .It Sy 1
-.Dl A fatal error occured.
+.Dl A fatal error occurred.
 .It Sy 2
 .Dl Invalid command line options were specified.
 .El
diff --git a/usr/src/man/man1/hostname.1 b/usr/src/man/man1/hostname.1
index 2dc4c542bb..74e9c16938 100644
--- a/usr/src/man/man1/hostname.1
+++ b/usr/src/man/man1/hostname.1
@@ -23,13 +23,15 @@ The super-user can set the hostname by giving
 .Ar name-of-host .
 .Pp
 While setting the hostname changes the hostname for the running system,
-it does not persist the change. The proper way to update the hostname
-will vary depending on how the system is configured. For most systems,
-the persistent hostname is stored in the file
+it does not persist the change.
+The proper way to update the hostname will vary depending on how the
+system is configured.
+For most systems, the persistent hostname is stored in the file
 .Pa /etc/nodename .
 See
 .Xr nodename 4
-for more information on how to update it. Note, the
+for more information on how to update it.
+Note, the
 .Pa /etc/nodename
 file may be ignored in cases where the system is configured to use DHCP.
 .Sh OPTIONS
diff --git a/usr/src/man/man1m/acpidump.1m b/usr/src/man/man1m/acpidump.1m
index 577a1deaef..4c24afcbea 100644
--- a/usr/src/man/man1m/acpidump.1m
+++ b/usr/src/man/man1m/acpidump.1m
@@ -70,11 +70,11 @@ Verbose.
 .Sy Example 1
 Dump all ACPI Tables
 .Pp
-The following example dumps all of the ACPI tables from the system. This
-can then be used with
+The following example dumps all of the ACPI tables from the system.
+This can then be used with
 .Xr acpixtract 1M
-and the iasl utility to decode the ACPI tables from the system. In this
-example, all of the tables are written to the file
+and the iasl utility to decode the ACPI tables from the system.
+In this example, all of the tables are written to the file
 .Pa acpi.out .
 .Bd -literal -offset width
 # acpidump -o acpi.dat
diff --git a/usr/src/man/man1m/acpixtract.1m b/usr/src/man/man1m/acpixtract.1m
index 309056c459..314dc4b7d2 100644
--- a/usr/src/man/man1m/acpixtract.1m
+++ b/usr/src/man/man1m/acpixtract.1m
@@ -65,10 +65,11 @@ Print the version.
 Extract all ACPI tables
 .Pp
 The following example extracts all of the individual ACPI tables from a
-previously created dump of the ACPI tables from a running system. Such a
-dump can be created with the
+previously created dump of the ACPI tables from a running system.
+Such a dump can be created with the
 .Xr acpidump 1M
-utility. Extracted tables can then be inspected or disassembled by the
+utility.
+Extracted tables can then be inspected or disassembled by the
 iasl utility on any platform.
 .Bd -literal -offset width
 # acpixtract -a acpi.dat
diff --git a/usr/src/man/man4/overlay_files.4 b/usr/src/man/man4/overlay_files.4
index a49b5cc73f..b9e5387871 100644
--- a/usr/src/man/man4/overlay_files.4
+++ b/usr/src/man/man4/overlay_files.4
@@ -23,10 +23,11 @@ The
 plugin provides a means for a dynamic overlay where the destinations are
 determined based on a static description contained in a
 .Sy JSON
-file. This manual describes the format of the file used by the
+file.
+This manual describes the format of the file used by the
 .Sy files/config
-property. To create and manage overlays
-with the
+property.
+To create and manage overlays with the
 .Sy files
 plugin, use
 .Xr dladm 1M .
@@ -35,27 +36,33 @@ For more information on overlays, see
 .Pp
 Using the
 .Sy files
-module, a static and simple overlay network can be created. This network
-does not support the use of
+module, a static and simple overlay network can be created.
+This network does not support the use of
 .Em broadcast
 or
 .Em multicast
-traffic. Both ARP and NDP traffic are proxied by the plugin itself. In
-addition, the plugin allows for DHCP. Instead of providing a traditional
-DHCP proxy, when an initial DHCP broadcast goes out to a broadcast
-address, it will get rewritten to target a specific MAC address. The
+traffic.
+Both ARP and NDP traffic are proxied by the plugin itself.
+In addition, the plugin allows for DHCP.
+Instead of providing a traditional DHCP proxy, when an initial DHCP broadcast
+goes out to a broadcast address, it will get rewritten to target a specific MAC
+address.
+The
 .Sy files
 plugin is useful as proof of concept and for simple static networks
-where addresses do not need to be reconfigured. If more advanced
-topologies or more streamlined updates are required, consider a different
-plugin.
+where addresses do not need to be reconfigured.
+If more advanced topologies or more streamlined updates are required, consider
+a different plugin.
 .Pp
 The file format is encoded as a series of
 .Sy JSON
-objects. Each object has a key, which is a MAC address on the
+objects.
+Each object has a key, which is a MAC address on the
 .Sy overlay
-network. It has multiple values, some required, some optional, which
-describe various properties. The valid properties are:
+network.
+It has multiple values, some required, some optional, which describe various
+properties.
+The valid properties are:
 .Bl -hang -width Ds
 .It Sy ip
 .Bd -filled -compact
@@ -63,14 +70,16 @@ The
 .Sy ip
 key indicates the IP address on the
 .Sy underlay
-network that houses the MAC address in question. Packets directed for
-the MAC address will be encapsulated and set to this address. This field
-is required.
+network that houses the MAC address in question.
+Packets directed for the MAC address will be encapsulated and set to this
+address.
+This field is required.
 .Pp
 The value is a
 .Em JSON String .
 Both IPv4 and IPv6 addresses are supported and should be written out in their
-traditional forms.  Follow the guidelines for writing addresses in
+traditional forms.
+Follow the guidelines for writing addresses in
 .Xr inet_aton 3SOCKET .
 .Ed
 .It Sy port
@@ -79,9 +88,10 @@ The
 .Sy port
 key indicates the port on the
 .Sy underlay
-network that houses the MAC address in question. This property is required if
-the encapsulation module requires a port for its destination. The value is
-a
+network that houses the MAC address in question.
+This property is required if the encapsulation module requires a port for its
+destination.
+The value is a
 .Em JSON Number .
 .Ed
 .It Sy arp
@@ -90,10 +100,12 @@ The
 .Sy arp
 key stores the IPv4 address that corresponds to this MAC address on the
 .Sy overlay
-network. This will be used to respond to ARP queries that would traditionally
-have been received by the OS kernel. If this address is not present, no IPv4
-packets directed to this IP address will be received by the network interface
-that has this MAC address, regardless of what is configured on top of it.
+network.
+This will be used to respond to ARP queries that would traditionally have been
+received by the OS kernel.
+If this address is not present, no IPv4 packets directed to this IP address will
+be received by the network interface that has this MAC address, regardless of
+what is configured on top of it.
 .Pp
 The value is a
 .Em JSON String
@@ -106,10 +118,12 @@ The
 .Sy ndp
 key stores the IPv6 address that corresponds to this MAC address on the
 .Sy overlay
-network. This will be used to respond to NDP queries that would traditionally
-have been received by the OS kernel. If this address is not present, no IPv6
-packets directed to this IP address will be received by the network interface
-that has this MAC address, regardless of what is configured on top of it.
+network.
+This will be used to respond to NDP queries that would traditionally have been
+received by the OS kernel.
+If this address is not present, no IPv6 packets directed to this IP address will
+be received by the network interface that has this MAC address, regardless of
+what is configured on top of it.
 .Pp
 The value is a
 .Em JSON String
@@ -121,8 +135,10 @@ and should be written out following the guidelines for IPv6 addresses in
 The
 .Sy dhcp-proxy
 key stores a MAC address that DHCP messages directed to a broadcast address get
-rewritten to be sent to. This can be viewed as a form of proxy DHCP, but is
-different in mechanism from a traditional proxy. The value is a
+rewritten to be sent to.
+This can be viewed as a form of proxy DHCP, but is different in mechanism from a
+traditional proxy.
+The value is a
 .Em JSON String
 and should be written as a traditional MAC address string as described by
 .Xr ether_aton 3SOCKET .
@@ -133,10 +149,12 @@ and should be written as a traditional MAC address string as described by
 Sample configuration file
 .Pp
 This configuration file provides information for three different MAC
-addresses. Each MAC address has an entry which describes what its IPv4
+addresses.
+Each MAC address has an entry which describes what its IPv4
 and IPv6 address is, as well as the IP address and port of the host on
-the underlay network. Finally, one host has a DHCP proxy entry to
-demonstrate how one might configure DHCP.
+the underlay network.
+Finally, one host has a DHCP proxy entry to demonstrate how one might
+configure DHCP.
 .Bd -literal -offset indent
 {
 	"de:ad:be:ef:00:00": {
diff --git a/usr/src/man/man5/lx.5 b/usr/src/man/man5/lx.5
index 0060f9ecfa..9ad903a396 100644
--- a/usr/src/man/man5/lx.5
+++ b/usr/src/man/man5/lx.5
@@ -24,9 +24,11 @@ brand
 uses the
 .Xr brands 5
 framework to provide an environment for running binary applications built
-for GNU/Linux. User-level code, including an entire Linux distribution, can
-run inside the zone. Both 32-bit and 64-bit applications are supported. The
-majority of Linux system calls are provided, along with emulation for a
+for GNU/Linux.
+User-level code, including an entire Linux distribution, can run inside the
+zone.
+Both 32-bit and 64-bit applications are supported.
+The majority of Linux system calls are provided, along with emulation for a
 variety of Linux file systems, such as
 .Em proc ,
 .Em cgroup
@@ -39,10 +41,11 @@ file system within the zone is a subset of a full Linux
 .Em /proc .
 Most kernel-level tuning applied to
 .Em /proc
-is unavailable or ignored. Some tuning can be performed, but only to reduce
-the overall limits that have been specified on the zone's configuration.
-That is, within the zone there is no way to increase the resource limits set
-on the zone itself.
+is unavailable or ignored.
+Some tuning can be performed, but only to reduce the overall limits that have
+been specified on the zone's configuration.
+That is, within the zone there is no way to increase the resource limits set on
+the zone itself.
 .Pp
 The zone must be installed using a clone of a
 .Xr zfs 1m
@@ -54,13 +57,14 @@ Example:
 Applications provided by the base SunOS operating system are also available
 within the zone under the
 .Em /native
-mount point. This allows the use of various native tools such as
+mount point.
+This allows the use of various native tools such as
 .Xr dtrace 1m ,
 .Xr mdb 1 ,
 or the
 .Xr proc 1
-tools on GNU/Linux applications. However, not every native tool will work
-properly within an
+tools on GNU/Linux applications.
+However, not every native tool will work properly within an
 .Em lx
 zone.
 .Sh CONFIGURATION
@@ -68,8 +72,8 @@ The
 .Em kernel-version
 attribute can be included in the zone's
 .Xr zonecfg 1m
-settings as a way to specify the Linux version that the zone is emulating. For
-example, the value could be
+settings as a way to specify the Linux version that the zone is emulating.
+For example, the value could be
 .Em 3.13.0 .
 .Sh LIMITATIONS
 The brand only supports the exclusive IP stack zone configuration.
@@ -77,24 +81,25 @@ The brand only supports the exclusive IP stack zone configuration.
 Most modern GNU/Linux application software runs on
 .Em lx ,
 but because there are some system calls or file systems which are not currently
-implemented, it's possible that an application won't run. This does not
-preclude the application running in the future as the
+implemented, it's possible that an application won't run.
+This does not preclude the application running in the future as the
 .Em lx
 brand adds new capabilities.
 .Pp
 Because there is only the single SunOS kernel running on the system, there
-is no support for any Linux kernel-level modules. That is, there is no support
-for add-on drivers or any other modules that are part of the Linux kernel
-itself. If that is required, a full virtual machine should be used instead of
-an
+is no support for any Linux kernel-level modules.
+That is, there is no support for add-on drivers or any other modules that are
+part of the Linux kernel itself.
+If that is required, a full virtual machine should be used instead of an
 .Em lx
 branded zone.
 .Pp
 Any core files produced within the zone are in the native SunOS format.
 .Pp
-As with any zone, the normal security mechanisms and privileges apply. Thus,
-certain operations (for example, changing the system time), will not be allowed
-unless the zone has been configured with the appropriate additional privileges.
+As with any zone, the normal security mechanisms and privileges apply.
+Thus, certain operations (for example, changing the system time), will not be
+allowed unless the zone has been configured with the appropriate additional
+privileges.
 .Sh SEE ALSO
 .Xr mdb 1 ,
 .Xr proc 1 ,
diff --git a/usr/src/man/man5/overlay.5 b/usr/src/man/man5/overlay.5
index c415cad4b6..4e884fd382 100644
--- a/usr/src/man/man5/overlay.5
+++ b/usr/src/man/man5/overlay.5
@@ -20,8 +20,8 @@
 .Sh DESCRIPTION
 Overlay devices are a GLDv3 device that allows users to create overlay
 networks that can be used to form the basis of network virtualization
-and software defined networking. Overlay networks allow a single
-physical network, often called an
+and software defined networking.
+Overlay networks allow a single physical network, often called an
 .Sy underlay
 network, to provide the means for creating multiple logical, isolated,
 and discrete layer two and layer three networks on top of it.
@@ -31,9 +31,11 @@ Overlay devices are administered through
 Overlay devices themselves cannot be plumbed up with
 .Sy IP ,
 .Sy vnd ,
-or any other protocol. Instead, like an
+or any other protocol.
+Instead, like an
 .Sy etherstub ,
-they allow for VNICs to be created on top of them. Like an
+they allow for VNICs to be created on top of them.
+Like an
 .Sy etherstub ,
 an overlay device acts as a local switch; however, when it encounters a
 non-local destination address, it instead looks up where it should send
@@ -50,45 +52,48 @@ How should a packet be transformed and put on the wire?
 Where should a transformed packet be sent?
 .El
 .Pp
-Each of these questions is answered by a plugin. The first question is
-answered by what's called an
+Each of these questions is answered by a plugin.
+The first question is answered by what's called an
 .Em encapsulation plugin .
 The second question is answered by what's called a
 .Em search plugin .
 Packets are encapsulated and decapsulated using the encapsulation plugin
-by the kernel. The search plugins are all user land plugins that are
-consumed by the varpd service whose FMRI is
+by the kernel.
+The search plugins are all user land plugins that are consumed by the
+varpd service whose FMRI is
 .Em svc:/network/varpd:default .
 This separation allows for the kernel to be responsible for the data
 path, while having the search plugins in userland allows the system to
 provide a much more expressive interface.
 .Ss Overlay Types
-Overlay devices come in
-two different flavors, one where all packets are always sent to a single
-address, the other, where the destination of a packet varies based on
-the target MAC address of the packet. This information is maintained in
-a
+Overlay devices come in two different flavors, one where all packets are
+always sent to a single address, the other, where the destination of a
+packet varies based on the target MAC address of the packet.
+This information is maintained in a
 .Em target table ,
-which is independent and unique to each overlay device. We call the
-plugins that send traffic to a single location, for example a single
-unicast or multicast IP address, a
+which is independent and unique to each overlay device.
+We call the plugins that send traffic to a single location, for example
+a single unicast or multicast IP address, a
 .Sy point to point
 overlay and the overlay devices that can send traffic to different
 locations based on the MAC address of that packet a
 .Sy dynamic
-overlay. The plugin type is determined based on the type of the
+overlay.
+The plugin type is determined based on the type of the
 .Sy search plugin .
 These are all fully listed in the section
 .Sx Plugins and their Properties .
 .Ss Overlay Destination
 Both encapsulation and search plugins define the kinds of destinations
-that they know how to support. An encapsulation plugin always has a
-single destination type that's determined based on how the encapsulation
-is defined. A search plugin, on the other hand, can support multiple
-combinations of destinations. A search plugin must support the
-destination type of the encapsulation device. The destination may
-require any of the following three pieces of information, depending on
-the encapsulation plugin:
+that they know how to support.
+An encapsulation plugin always has a single destination type that's
+determined based on how the encapsulation is defined.
+A search plugin, on the other hand, can support multiple combinations of
+destinations.
+A search plugin must support the destination type of the encapsulation
+device.
+The destination may require any of the following three pieces of
+information, depending on the encapsulation plugin:
 .Bl -hang -width Ds
 .It Sy MAC Address
 .Bd -filled -compact
@@ -96,7 +101,8 @@ An Ethernet MAC address is required to determine the destination.
 .Ed
 .It Sy IP Address
 .Bd -filled -compact
-An IP address is required. Both IPv4 and IPv6 addresses are supported.
+An IP address is required.
+Both IPv4 and IPv6 addresses are supported.
 .Ed
 .It Sy Port
 .Bd -filled -compact
@@ -109,15 +115,17 @@ encapsulation plugins is listed in the section
 .Sx Plugins and their Properties .
 .Ss varpd
 The varpd service, mentioned above, is responsible for providing the
-virtual ARP daemon. Its responsibility is conceptually similar to ARP.
+virtual ARP daemon.
+Its responsibility is conceptually similar to ARP.
 It runs all instances of search plugins in the system and is responsible
 for answering the kernel's ARP-like questions for where packets should
 be sent.
 .Pp
 The varpd service, svc:/network/varpd:default, must be enabled for
-overlay devices to function. If it is disabled while there are active
-devices, then most overlay devices will not function correctly and
-likely will end up dropping traffic.
+overlay devices to function.
+If it is disabled while there are active devices, then most overlay
+devices will not function correctly and likely will end up dropping
+traffic.
 .Sh PLUGINS AND PROPERTIES
 Properties fall into three categories in the system:
 .Bl -enum -offset indent -compact
@@ -137,8 +145,9 @@ link properties:
 .It Sy Name
 .Bd -filled -compact
 The name of a property is namespaced by its module and always structured
-and referred to as as module/property. This allows for both an
-encapsulation and search plugin to have a property with the same name.
+and referred to as as module/property.
+This allows for both an encapsulation and search plugin to have a
+property with the same name.
 Properties that are valid for all overlay devices and not specific to a
 module do not generally use a module prefix.
 .Pp
@@ -153,8 +162,8 @@ encapsulation module.
 Each property in the system has a type.
 .Xr dladm 1M
 takes care of converting between the internal representation and a
-value, but the type influences the acceptable input range. The types
-are:
+value, but the type influences the acceptable input range.
+The types are:
 .Bl -hang -width Ds
 .It Sy INT
 A signed integer that is up to eight bytes long
@@ -163,13 +172,14 @@ A signed integer that is up to eight bytes long
 An unsigned integer that is up to eight bytes long
 .Pq Sy uint64_t .
 .It Sy IP
-Either an IPv4 or IPv6 address in traditional string form. For example,
-192.168.128.23 or 2001:470:8af4::1:1. IPv4 addresses may also be encoded
-as IPv4-mapped IPv6 addresses.
+Either an IPv4 or IPv6 address in traditional string form.
+For example, 192.168.128.23 or 2001:470:8af4::1:1.
+IPv4 addresses may also be encoded as IPv4-mapped IPv6 addresses.
 .It Sy STRING
 A string of ASCII or UTF-8 encoded characters terminated with a
 .Sy NUL
-byte. The maximum string length, including the terminator, is currently
+byte.
+The maximum string length, including the terminator, is currently
 256 bytes.
 .El
 .Ed
@@ -183,9 +193,11 @@ This generally includes things like the overlay's encapsulation module.
 .It Sy Required
 .Bd -filled -compact
 This property indicates whether the property is required for the given
-plugin. If it is not specified during a call to
+plugin.
+If it is not specified during a call to
 .Sy dladm create-overlay ,
-then the overlay cannot be successfully created. Properties which have a
+then the overlay cannot be successfully created.
+Properties which have a
 .Sy default
 will use that value if one is not specified rather than cause the
 overlay creation to fail.
@@ -197,33 +209,36 @@ Required properties always have a value set.
 .Ed
 .It Sy Default Value
 .Bd -filled -compact
-The default value is an optional part of a given property. If a property
-does define a default value, then it will be used when an overlay is
-created and no other value is given.
+The default value is an optional part of a given property.
+If a property does define a default value, then it will be used when an
+overlay is created and no other value is given.
 .Ed
 .It Sy Value ranges
 .Bd -filled -compact
-Value ranges are an optional part of a given property. They indicate a
-range or set of values that are valid and may be set for a property. A
-property may not declare such a range as it may be impractical or
-unknown. For example, most properties based on IP addresses will not
+Value ranges are an optional part of a given property.
+They indicate a range or set of values that are valid and may be set for
+a property.
+A property may not declare such a range as it may be impractical or
+unknown.
+For example, most properties based on IP addresses will not
 declare a range.
 .Ed
 .El
 .Pp
 The following sections describe both the modules and the properties that
 exist for each module, noting their name, type, permissions, whether or
-not they are required, and if there is a default value. In addition, the
-effects of each property will be described.
+not they are required, and if there is a default value.
+In addition, the effects of each property will be described.
 .Ss Encapsulation Plugins
 .Bl -hang -width Ds
 .It Sy vxlan
 The
 .Sy vxlan
-module is a UDP based encapsulation method. It takes a frame that would
-be put on the wire, wraps it up in a VXLAN header and places it in a UDP
-packet that gets sent out on the underlying network. For more details
-about the specific format of the VXLAN header, see
+module is a UDP based encapsulation method.
+It takes a frame that would be put on the wire, wraps it up in a VXLAN
+header and places it in a UDP packet that gets sent out on the
+underlying network.
+For more details about the specific format of the VXLAN header, see
 .Xr vxlan 7P .
 .Pp
 The
@@ -232,7 +247,8 @@ module requires both an
 .Sy IP address
 and
 .Sy port
-to address it. It has a 24-bit virtual network ID space, allowing for
+to address it.
+It has a 24-bit virtual network ID space, allowing for
 virtual network identifiers that range from
 .Sy 0
 -
@@ -274,7 +290,8 @@ Range:
 The
 .Sy vxlan/listen_port
 property determines the UDP port that the system will listen on for
-VXLAN traffic for this overlay. The default value is
+VXLAN traffic for this overlay.
+The default value is
 .Sy 4789 ,
 the IANA assigned port for VXLAN.
 .Ed
@@ -285,10 +302,11 @@ The
 and
 .Sy vxlan/listen_port
 properties determine how the system will accept VXLAN encapsulated
-packets for this interface. It does not determine the interface that
-packets will be sent out over. Multiple overlays that all use VXLAN can
-share the same IP and port combination, as the virtual network
-identifier can be used to tell the different overlays apart.
+packets for this interface.
+It does not determine the interface that packets will be sent out over.
+Multiple overlays that all use VXLAN can share the same IP and port
+combination, as the virtual network identifier can be used to tell the
+different overlays apart.
 .El
 .Ss Search Plugins
 Because search plugins may support multiple destinations, they may have
@@ -296,9 +314,9 @@ more properties listed than necessarily show up for a given overlay.
 For example, the
 .Sy direct
 plugin supports destinations that are identified by both an IP address
-and a port, or just an IP address. In cases where the device is created
-over an overlay that only uses an IP address for its destination, then
-it will not have the
+and a port, or just an IP address.
+In cases where the device is created over an overlay that only uses an
+IP address for its destination, then it will not have the
 .Sy direct/dest_port
 property.
 .Bl -hang -width Ds
@@ -306,8 +324,8 @@ property.
 The
 .Sy direct
 plugin is a point to point module that can be used to create an overlay
-that forwards all non-local traffic to a single destination. It supports
-destinations that are a combination of an
+that forwards all non-local traffic to a single destination.
+It supports destinations that are a combination of an
 .Sy IP Address
 and a
 .Sy port .
@@ -358,12 +376,13 @@ The
 .Sy files
 plugin implements a
 .Sy dynamic
-plugin that specifies where traffic should be sent based on a file. It
-is a glorified version of /etc/ethers. The
+plugin that specifies where traffic should be sent based on a file.
+It is a glorified version of /etc/ethers.
+The
 .Sy dynamic
 plugin does not support broadcast or multicast traffic, but it has
-support for proxy ARP, NDP, and DHCPv4. For the full details of the file
-format, see
+support for proxy ARP, NDP, and DHCPv4.
+For the full details of the file format, see
 .Xr overlay_files 4 .
 .Pp
 The
@@ -381,16 +400,16 @@ Permissions:
 .Bd -filled
 The
 .Sy files/config
-property specifies an absolute path to a file to read. The file is a
-JSON file that is formatted according to
+property specifies an absolute path to a file to read.
+The file is a JSON file that is formatted according to
 .Xr overlay_files 4 .
 .Ed
 .El
 .El
 .Ss General Properties
 Each overaly has the following properties which are used to give
-additional information about the system. None of these properties may be
-specified as part of a
+additional information about the system.
+None of these properties may be specified as part of a
 .Sy dladm create-overlay ,
 instead they come from other arguments or from internal parts of the
 system.
@@ -421,12 +440,13 @@ Range:
 .Bd -filled
 The
 .Sy mtu
-property describes the maximum transmission unit of the overlay. The
-default value is
+property describes the maximum transmission unit of the overlay.
+The default value is
 .Sy 1400
 bytes, which ensures that in a traditional deployment with an MTU of
 1500 bytes, the overhead that is added from encapsulation is all
-accounted for. It is the administrator's responsibility to ensure that
+accounted for.
+It is the administrator's responsibility to ensure that
 the device's MTU and the encapsulation overhead does not exceed that of
 the interfaces that the encapsulated traffic will be sent out of.
 .Pp
@@ -477,11 +497,12 @@ encapsulation engine.
 Overlay devices are wired into FMA, the illumos fault management
 architecture, and generates error reports depending on the
 .Sy search
-plugin in use. Due to limitations in FMA today, when a single overlay
+plugin in use.
+Due to limitations in FMA today, when a single overlay
 enters a degraded state, meaning that it cannot properly perform look
 ups or another error occurred, then it degrades the overall
 .Sy overlay
-psuedo-device driver.
+pseudo-device driver.
 .Pp
 For more fine-grained information about which overlay is actually in a
 .Em degraded
@@ -491,8 +512,9 @@ In addition, for each overlay in a degraded state a more useful
 diagnostic message is provided which describes the reason that caused
 this overlay to enter into a degraded state.
 .Pp
-The overlay driver is self-healing. If the problem corrects itself on
-its own, it will clear the fault on the corresponding device.
+The overlay driver is self-healing.
+If the problem corrects itself on its own, it will clear the fault on
+the corresponding device.
 .Sh SEE ALSO
 .Xr dladm 1M ,
 .Xr overlay_files 4 ,
diff --git a/usr/src/man/man7d/zfd.7d b/usr/src/man/man7d/zfd.7d
index 71b3084fdc..cbdc869819 100644
--- a/usr/src/man/man7d/zfd.7d
+++ b/usr/src/man/man7d/zfd.7d
@@ -38,10 +38,10 @@ The zone's zfd device configuration is driven by
 .Nm zoneadmd
 and a zone attribute
 .Nm zlog-mode
-which is somewhat of a misnomer since its purpose has evolved. The attribute
-can have a variety of values, but the lowest two positions in the value string
-are used to control how many zfd devices are created inside the zone and if the
-primary stream is a tty.
+which is somewhat of a misnomer since its purpose has evolved.
+The attribute can have a variety of values, but the lowest two positions
+in the value string are used to control how many zfd devices are created
+inside the zone and if the primary stream is a tty.
 .sp
 .Dl --
 .Dl -n
@@ -61,19 +61,19 @@ That is,
 .Nm ldterm
 and
 .Nm ttycompat
-are autopushed onto the stream when the slave side is opened. There is only a
-single zfd device (0) needed for the primary stream.
+are autopushed onto the stream when the slave side is opened.
+There is only a single zfd device (0) needed for the primary stream.
 .sp
 When the
 .Nm n
 flag is set, it is assumed that output logging will be done within the zone
-itself. In this configuration 1 or 2 additional zfd devices, depending on tty
-mode
+itself.
+In this configuration 1 or 2 additional zfd devices, depending on tty mode
 .Nm ( t
-flag), are created within the zone. An application can then configure the
-zfd streams driver into a multiplexer. Output from the stdout/stderr zfd(s)
-will be teed into the correspond logging zfd(s) within the zone.
-.sp
+flag), are created within the zone.
+An application can then configure the zfd streams driver into a multiplexer.
+Output from the stdout/stderr zfd(s) will be teed into the correspond
+logging zfd(s) within the zone.
 .Sh SEE ALSO
 .Xr zlogin 1 ,
 .Xr zoneadmd 1M ,
diff --git a/usr/src/man/man7m/datafilt.7m b/usr/src/man/man7m/datafilt.7m
index f74ac0b103..f840e389c8 100644
--- a/usr/src/man/man7m/datafilt.7m
+++ b/usr/src/man/man7m/datafilt.7m
@@ -23,13 +23,15 @@ The
 .Nm datafilt
 socket filter provides deferment of
 .Xr accept 3SOCKET
-for TCP connections. The accept call will not return until at least
-one byte has been buffered by the kernel. Deferment assures the
-application that the first call to
-.Xr read 2 or
+for TCP connections.
+The accept call will not return until at least one byte has been
+buffered by the kernel.
+Deferment assures the application that the first call to
+.Xr read 2
+or
 .Xr recv 3SOCKET
-will not block. It reduces unnecessary switching between user and
-kernel.
+will not block.
+It reduces unnecessary switching between user and kernel.
 .Sh EXAMPLES
 .Ss Example 1
 Enable deferment on the listening socket.
diff --git a/usr/src/man/man7p/vxlan.7p b/usr/src/man/man7p/vxlan.7p
index a32637b484..43c4756585 100644
--- a/usr/src/man/man7p/vxlan.7p
+++ b/usr/src/man/man7p/vxlan.7p
@@ -24,24 +24,27 @@
 .Nm
 (RFC 7348) is a network encapsulation protocol that is used by
 .Xr overlay 5
-devices. A payload, commonly an Ethernet frame, is placed inside of a
+devices.
+A payload, commonly an Ethernet frame, is placed inside of a
 UDP packet and prepended with an 8-byte
 .Nm
 header.
 .Pp
 The
 .Nm
-header contains two 32-bit words. The first word is an 8-bit flags field
-followed by 24 reserved bits. The second word is a 24-bit virtual network
-identifier followed by 8 reserved bits. The virtual network identifier
-identifies a unique
+header contains two 32-bit words.
+The first word is an 8-bit flags field followed by 24 reserved bits.
+The second word is a 24-bit virtual network identifier followed by 8
+reserved bits.
+The virtual network identifier identifies a unique
 .Nm
 and
 is similar in concept to an IEEE 802.1Q VLAN identifier.
 .Pp
 The system provides access to
 .Nm
-through dladm overlays. See
+through dladm overlays.
+See
 .Xr dladm 1M
 and
 .Xr overlay 5
@@ -51,10 +54,12 @@ The
 .In sys/vxlan.h
 header provides information for working with the
 .Nm
-protocol. The contents of this header are
+protocol.
+The contents of this header are
 .Sy uncommitted .
 The header defines a structure that may be used to encode and decode a VXLAN
-header. It defines a packed structure type
+header.
+It defines a packed structure type
 .Sy vxlan_hdr_t
 which represents the
 .Nm
@@ -70,7 +75,8 @@ Decoding a
 header
 .Pp
 The following example shows how to validate a
-.Nm header. For more information on this process, see RFC 7348.
+.Nm header.
+For more information on this process, see RFC 7348.
 .Bd -literal -offset indent
 #include <sys/types.h>
 #include <netinet/in.h>
diff --git a/usr/src/man/man9/iport.9 b/usr/src/man/man9/iport.9
index 1179f87470..4ffeb3faaa 100644
--- a/usr/src/man/man9/iport.9
+++ b/usr/src/man/man9/iport.9
@@ -29,10 +29,10 @@ and
 .Sy tgtmap
 abstractions enable host bus adapter (HBA) drivers to represent the
 devices that they are responsible for enumerating, as well as the
-relationships between these devices. These interfaces simplify device
-drivers by taking care of the creation and destruction of device nodes
-in the devices tree for enumerated devices as well as performing some
-amount of hysteresis.
+relationships between these devices.
+These interfaces simplify device drivers by taking care of the creation
+and destruction of device nodes in the devices tree for enumerated
+devices as well as performing some amount of hysteresis.
 .Pp
 These abstractions are used in tandem with SCSI complex addressing. A
 device driver that uses these interfaces generally passes both the
@@ -46,81 +46,92 @@ argument to
 .Ss iport
 The
 .Sy iport ,
-or initiator port, abstracts a collection of attached devices. One way
-to view an iport is that each iport maps to a phy on the HBA. A phy
-refers to a physical connector between the HBA and devices. A phy may be
-made up of individual lanes. A lane is connected to a device, for
-example a disk driver. Multiple lanes maybe plugged into the same
-device, for example, an expander.  When a phy connects to a device with
-a single lane, this is often called a
+or initiator port, abstracts a collection of attached devices.
+One way to view an iport is that each iport maps to a phy on the HBA.
+A phy refers to a physical connector between the HBA and devices.
+A phy may be made up of individual lanes.
+A lane is connected to a device, for example a disk driver.
+Multiple lanes maybe plugged into the same device, for example, an
+expander.
+When a phy connects to a device with a single lane, this is often
+called a
 .Em narrow phy .
 When a phy connects to a device with multiple lanes, this is often
 called a
 .Em wide phy .
 .Pp
-Consider a device that has two physical ports, and thus two phys. Each
-phy has four lanes, thus we describe the phy as having a mask of 0xf.
-Each bit in the mask corresponds to a specific lane. In this example,
-each phy would be represented in the system by an iport and may
-enumerate a different device for each lane of the phy. If an expander is
-attached to one or more of the lanes of a phy, then additional devices
-will be enumerated under the expander and be added to that phy's iport.
+Consider a device that has two physical ports, and thus two phys.
+Each phy has four lanes, thus we describe the phy as having a mask of
+0xf.
+Each bit in the mask corresponds to a specific lane.
+In this example, each phy would be represented in the system by an iport
+and may enumerate a different device for each lane of the phy.
+If an expander is attached to one or more of the lanes of a phy, then
+additional devices will be enumerated under the expander and be added to
+that phy's iport.
 .Pp
 Another example to consider is when each lane of a phy is directly
-connected to a single disk through a passive backplane. In this case,
-each lane may represent its own iport, since the management of each is
-independent, basically there are many devices each with a mask of 0x1.
+connected to a single disk through a passive backplane.
+In this case, each lane may represent its own iport, since the
+management of each is independent, basically there are many devices each
+with a mask of 0x1.
 .Pp
-iports do not need to map to a physical phy. Some HBAs support a
-combination of both physical and virtual devices. In that case, the
-driver may create two different iports, one for the physical devices and
-one for the virtual devices.
+iports do not need to map to a physical phy.
+Some HBAs support a combination of both physical and virtual devices.
+In that case, the driver may create two different iports, one for the
+physical devices and one for the virtual devices.
 .Pp
 One property of iports is that they're attached separately from the main
 device and therefore have their own
 .Xr scsi_hba_tran 9S
-structure. As a result, that means that a driver can provide different
+structure.
+As a result, that means that a driver can provide different
 entry points for each iport, especially if they represent different
 classes of resources, for example one iport for all physical devices and
-one for all virtual devices. This allows for a driver to return
-different capabilities, among other behaviors and entry points, for
-these different iports. One specific case of this is that while physical
-devices may provide a means to get to a SCSI WWN, virtual devices may
-not have a WWN and instead must use a different addressing format.
+one for all virtual devices.
+This allows for a driver to return different capabilities, among other
+behaviors and entry points, for these different iports.
+One specific case of this is that while physical devices may provide a
+means to get to a SCSI WWN, virtual devices may not have a WWN and
+instead must use a different addressing format.
 .Pp
 iports are considered children of the device driver that attach them,
-but they are bound to the same driver. This means that when an iport
-is created, the
+but they are bound to the same driver.
+This means that when an iport is created, the
 .Xr attach 9E
 and
 .Xr probe 9E
 entry points of the parent driver (usually indicated by passing a
 .Vt dev_info
-structure) will be called. Similarly, when an iport is removed from the
-system, then the driver's
+structure) will be called.
+Similarly, when an iport is removed from the system, then the driver's
 .Xr detach 9E
-entry point will be called. A driver can determine whether an iport is
-being attached or not by calling the
+entry point will be called.
+A driver can determine whether an iport is being attached or not by
+calling the
 .Xr scsi_hba_iport_unit_address 9F
-function. The value will return
+function.
+The value will return
 .Dv NULL
 if the attaching device represents the driver.
 .Pp
-To manage iports, drivers have two different options. If the set of
-iport an HBA supports are static, then they should use the
+To manage iports, drivers have two different options.
+If the set of iport an HBA supports are static, then they should use the
 .Xr scsi_hba_iport_register 9F
 function to register an iport.
 .Pp
 If instead, the set of iports are dynamic and map to the coming and
 going of phys discovered by the driver (or some other dynamic source),
-then the driver should use the iportmap set of functions. See the
-section
+then the driver should use the iportmap set of functions.
+See the section
 .Sx phymap and iportmap
 for more information.
 .Ss tgtmap
 The target map represents a set of devices that have been enumerated
-under an iport. Each device is represented by a string, which is an
-address of some kind. Usually a physical device's WWN is used.
+under an iport.
+Each device is represented by a string, which is an address of some
+kind.
+Usually a physical device's WWN is used.
 .Pp
 By using a target map, the operating system will take
 responsibility for notifying the driver when devices have come and gone
@@ -139,26 +150,30 @@ Per-address
 .El
 .Pp
 In the full-set mode, the driver always reports the full set of current
-devices that it sees. When the driver finishes the report, the operating
-system will inform the driver of addresses that were added and addresses
-that were removed. These addresses correspond to newly found devices and
-recently removed devices, respectively. The full-set mode allows for a
-simpler device driver, particularly if addition and removal
-notifications may be dropped by the hardware.
+devices that it sees.
+When the driver finishes the report, the operating system will inform
+the driver of addresses that were added and addresses that were removed.
+These addresses correspond to newly found devices and recently removed
+devices, respectively.
+The full-set mode allows for a simpler device driver, particularly if
+addition and removal notifications may be dropped by the hardware.
 .Pp
 When using the per-address mode of a target map, the HBA driver is
 responsible for indicating which addresses have come and gone from the
 system.
 .Pp
 In either mode, the driver will receive two callbacks, if they have been
-registered when the target map was created. The first callback fires
-before a target driver like sd, ses, etc. is attached. The second
-callback fires after the corresponding driver has been attached. These
-allow the HBA driver to perform any operations that are required on the
-devices.
+registered when the target map was created.
+The first callback fires before a target driver like sd, ses, etc. is
+attached.
+The second callback fires after the corresponding driver has been
+attached.
+These allow the HBA driver to perform any operations that are
+required on the devices.
 .Pp
 Each target map has two different sets of devices that it manages in
-this form. The devices are separated into the following groups:
+this form.
+The devices are separated into the following groups:
 .Bl -enum
 .It
 SCSI Devices
@@ -198,36 +213,43 @@ per-address mode:
 .El
 .Ss phymap and iportmap
 The phymap and iportmap are often used together to represent complex SAS
-topologies. The phymap provides a way to see what phys have been grouped
-together under the same SAS port. The SAS port is represented by the
+topologies.
+The phymap provides a way to see what phys have been grouped together
+under the same SAS port.
+The SAS port is represented by the
 .Dq local
 and
 .Dq remote
-WWNs. When additional phys come online, if they end up referring to the
+WWNs.
+When additional phys come online, if they end up referring to the
 same WWNs, then they'll map to the same port.
 .Pp
 The iportmap is used to maintain a dynamic set of iports related to a
-device. The iports are each identified by an address, which is generally
-a unit address string. For example, when a new phy is added to the
-phymap which represents a new SAS port being used, then a corresponding
-iport will be created and associated with that entry from the phymap.
+device.
+The iports are each identified by an address, which is generally
+a unit address string.
+For example, when a new phy is added to the phymap which represents a
+new SAS port being used, then a corresponding iport will be created and
+associated with that entry from the phymap.
 Once the iport has been created, a normal target map can be created on
 top of it to handle detected SCSI and SMP devices.
 .Pp
 Both the phymap and iportmap operate in a similar fashion to the
-per-address mode of a tgtmap. Entries can be added and removed through
-direct functions. The phymap provides callbacks similar to the tgtmap;
-however, the iportmap does not. This is because when an iport is added
-or removed, a new node is added to the devices tree and the driver's
+per-address mode of a tgtmap.
+Entries can be added and removed through direct functions.
+The phymap provides callbacks similar to the tgtmap; however, the
+iportmap does not.
+This is because when an iport is added or removed, a new node is added
+to the devices tree and the driver's
 .Xr attach 9E
 entry point is called with a new
 .Vt dev_info_t
 structure representing the iport.
 .Pp
 During the phymap callback, the HBA driver should create a new iport
-with the unit address passed in from the callback function. This
-relationship is important when taking advantage of the ability to map
-between an iport and the set of phys that it represents.
+with the unit address passed in from the callback function.
+This relationship is important when taking advantage of the ability to
+map between an iport and the set of phys that it represents.
 .Pp
 The following functions are used to manage iportmaps:
 .Bl -dash
@@ -255,25 +277,29 @@ The following functions are used to manage phymaps:
 .Ss SCSI Complex Addressing
 Traditionally, SCSI devices were represented by a simple structure, the
 .Xr scsi_address 9S .
-This represented devices by a simple target and lun number. While this
-interface is useful for simple devices and traditional parallel SCSI
-devices, it is not as useful for SAS-era devices where the SCSI bus is
-now a fabric. A driver may opt into such a complex addressing mode by
-setting the
+This represented devices by a simple target and lun number.
+While this interface is useful for simple devices and traditional
+parallel SCSI devices, it is not as useful for SAS-era devices where the
+SCSI bus is now a fabric.
+A driver may opt into such a complex addressing mode by setting the
 .Dv SCSI_HBA_ADDR_COMPLEX
 flag.
 .Pp
 When this flag is set, the HBA driver must treat the SCSI address
-as an opaque structure. Once in this mode, the driver may get and set a
-private data structure on the SCSI device. This is facilitated by the
+as an opaque structure.
+Once in this mode, the driver may get and set a private data structure
+on the SCSI device.
+This is facilitated by the
 .Xr scsi_device_hba_private_set 9F
 and
 .Xr scsi_device_hba_private_get 9F
-functions.  In addition, the system provides a means to map between the
+functions.
+In addition, the system provides a means to map between the
 .Xr scsi_address 9S
 structure and the corresponding
 .Xr scsi_device 9S
-structure. This is performed by the
+structure.
+This is performed by the
 .Xr scsi_device_unit_address 9F
 function.
 .Sh SEE ALSO
diff --git a/usr/src/man/man9e/mac_capab_led.9e b/usr/src/man/man9e/mac_capab_led.9e
index 5983262569..cf6b3713d3 100644
--- a/usr/src/man/man9e/mac_capab_led.9e
+++ b/usr/src/man/man9e/mac_capab_led.9e
@@ -30,8 +30,8 @@
 .Fc
 .Sh INTERFACE LEVEL
 .Sy Evolving -
-This interface is still evolving. API and ABI stability is
-not guaranteed.
+This interface is still evolving.
+API and ABI stability is not guaranteed.
 .Sh PARAMETERS
 .Bl -tag -width Fa
 .It Fa driver
@@ -43,7 +43,8 @@ structure to the
 .Xr mac_register 9F
 function.
 .It Fa mode
-A value that indicates how the driver should drive the LEDs. See the
+A value that indicates how the driver should drive the LEDs.
+See the
 .Sx LED MODES
 section for a list of supported modes.
 .It Fa flags
@@ -53,33 +54,39 @@ Reserved for future use.
 The
 .Sy MAC_CAPAB_LED
 capability allows GLDv3 device drivers to expose an interface for
-controlling the LEDs on the device. This allows the system to control
-the LEDs to assist system administrators in finding and identifying
-specific physical devices in the system.
+controlling the LEDs on the device.
+This allows the system to control the LEDs to assist system
+administrators in finding and identifying specific physical devices in
+the system.
 .Pp
-Implementing this capability is optional. For more information on how to
-handle capabilities and how to indicate that a capability is not
-supported, see
+Implementing this capability is optional.
+For more information on how to handle capabilities and how to indicate
+that a capability is not supported, see
 .Xr mc_getcapab 9E .
 .Pp
 This capability should be implemented if the device in question provides
-a way to manipulate its LEDs. Generally the LEDs on a device default to
-indicating link status and activity. However, they can often be turned
-off or set to a specific pattern for identification purposes.
+a way to manipulate its LEDs.
+Generally the LEDs on a device default to indicating link status and
+activity.
+However, they can often be turned off or set to a specific pattern for
+identification purposes.
 .Ss LED MODES
-The system has a notion of different LED modes. Each LED mode suggests a
-different way that a device driver should drive the indicator LEDs on
-the device. While we generally want all such LED modes to be as uniform
+The system has a notion of different LED modes.
+Each LED mode suggests a different way that a device driver should drive
+the indicator LEDs on the device.
+While we generally want all such LED modes to be as uniform
 as possible, there is a limit to such similarities due to the
-capabilities of NICs. Each mode is a member of the
+capabilities of NICs.
+Each mode is a member of the
 .Vt mac_led_mode_t
-enumeration. The currently defined modes are:
+enumeration.
+The currently defined modes are:
 .Bl -tag -width Dv -offset indent
 .It Dv MAC_LED_DEFAULT
 This mode indicates that the device's default behavior should be used.
-This is usually some form of link status and activity. It is device
-specific and usually is the default behavior after a device is powered
-on.
+This is usually some form of link status and activity.
+It is device specific and usually is the default behavior after a device
+is powered on.
 .It Dv MAC_LED_OFF
 This mode indicates that the device's LEDs should be turned off and not
 emit any light.
@@ -88,11 +95,12 @@ This mode indicates that the device's LEDs should be turned on and
 remain solid.
 .It Dv MAC_LED_IDENT
 This mode indicates that the driver should emit some form of
-identification pattern. We suggest that devices indicate some form of
-solid blinking light that is on and off at alternating units of time,
-for example, every 200 milliseconds. If it is possible to use an
-alternate color from the normal link up and activity lighting, that is
-recommended.
+identification pattern.
+We suggest that devices indicate some form of solid blinking light that
+is on and off at alternating units of time, for example, every 200
+milliseconds.
+If it is possible to use an alternate color from the normal link up and
+activity lighting, that is recommended.
 .El
 .Ss MAC Capability Structure
 When the device driver's
@@ -117,19 +125,20 @@ rules:
 .It Fa mcl_flags
 The
 .Fa mcl_flags
-member is used to negotiate extensions with the driver. MAC will set the
-value of
+member is used to negotiate extensions with the driver.
+MAC will set the value of
 .Fa mcl_flags
-to include all of the currently known extensions. The driver should
-intersect this list with the set that they actually support. At this
-time, no such features are defined and the driver should set the member
-to
+to include all of the currently known extensions.
+The driver should intersect this list with the set that they actually
+support.
+At this time, no such features are defined and the driver should set the
+member to
 .Sy 0 .
 .It Fa mcl_modes
 The
 .Fa mcl_modes
-member represents the support modes of the device driver. The device
-driver should set
+member represents the support modes of the device driver.
+The device driver should set
 .Vt mcl_modes
 to the bitwise-inclusive-OR of the LED modes listed in
 .Sx LED MODES .
@@ -143,26 +152,29 @@ capability.
 The
 .Fa mcl_set
 entry point will be called by the MAC framework when it needs the device
-driver to change how it is driving its LEDs. Each call will ask the
-driver to change the display mode to the specified mode. The driver does
-not have to multiplex requests for multiple modes or keep track of what
-has been requested, that is taken care of by the system itself.
+driver to change how it is driving its LEDs.
+Each call will ask the driver to change the display mode to the
+specified mode.
+The driver does not have to multiplex requests for multiple modes or
+keep track of what has been requested, that is taken care of by the
+system itself.
 .Pp
 The driver should first validate that
 .Fa mode
-is a mode that it supports. While the device reports the set of
-supported modes as a bitwise-inclusive-OR, the driver should only
-receive a single value in
+is a mode that it supports.
+While the device reports the set of supported modes as a
+bitwise-inclusive-OR, the driver should only receive a single value in
 .Fa mode .
 The value of the
 .Fa flags
-argument is reserved for future use. Drivers must check that the value
-of flags is zero and if not, return
+argument is reserved for future use.
+Drivers must check that the value of flags is zero and if not, return
 .Er EINVAL .
 .Pp
 When this entry point is first called on a driver, it should snapshot
 its device registers such that it knows how to restore the default
-behavior. Because each method of programming the LEDs is different, it
+behavior.
+Because each method of programming the LEDs is different, it
 is up to the driver itself to take care of this, the broader framework
 cannot take care of it.
 .Pp
@@ -173,8 +185,8 @@ return success.
 Once the driver successfully changes the LED driving mode, it should
 return
 .Sy 0 .
-Otherwise, it should return the appropriate error number. For a full
-list of error numbers, see
+Otherwise, it should return the appropriate error number.
+For a full list of error numbers, see
 .Xr Intro 2 .
 Common values are:
 .Bl -tag -width Er -offset width
@@ -194,8 +206,8 @@ encountered an error.
 .Pp
 The broader framework will guarantee that only a single call to the
 .Fa mcl_set
-function is ongoing at any time. If other parts of the driver refer to
-the data used by the
+function is ongoing at any time.
+If other parts of the driver refer to the data used by the
 .Fa mcl_set
 function, then the driver must ensure that it is performing sufficient
 locking of its data.
@@ -207,7 +219,8 @@ entry point will only be called from
 .Sy user
 or
 .Sy kernel
-context. It will never be called from interrupt context.
+context.
+It will never be called from interrupt context.
 .Sh SEE ALSO
 .Xr Intro 2 ,
 .Xr mac 9E ,
diff --git a/usr/src/man/man9e/mac_capab_transceiver.9e b/usr/src/man/man9e/mac_capab_transceiver.9e
index 6f14666a08..7626fe5fed 100644
--- a/usr/src/man/man9e/mac_capab_transceiver.9e
+++ b/usr/src/man/man9e/mac_capab_transceiver.9e
@@ -40,7 +40,8 @@
 .Fc
 .Sh INTERFACE LEVEL
 .Sy Volatile -
-This interface is still evolving in illumos. API and ABI stability is
+This interface is still evolving in illumos.
+API and ABI stability is
 not guaranteed.
 .Sh PARAMETERS
 .Bl -tag -width Fa
@@ -75,43 +76,51 @@ bytes.
 The
 .Sy MAC_CAPAB_TRANSCEIVER
 capability allows for GLDv3 networking device drivers to provide
-information to the system about their transceiver. Implementing this
-capability is optional. For more information on how to handle
-capabilities and how to indicate that a capability is not supported, see
+information to the system about their transceiver.
+Implementing this capability is optional.
+For more information on how to handle capabilities and how to indicate
+that a capability is not supported, see
 .Xr mc_getcapab 9E .
 .Pp
 This capability should be implemented if the device in question supports
-a Small Form Factor (SFF) transceiver. These are more commonly known by
-names such as SFP, SFP+, SFP28, QSFP+, and QSFP28. This interface does
-not apply to traditional copper Ethernet phys. These transceivers
-provide standardized information over the i2c bus at specific pages.
+a Small Form Factor (SFF) transceiver.
+These are more commonly known by names such as SFP, SFP+, SFP28, QSFP+,
+and QSFP28.
+This interface does not apply to traditional copper Ethernet phys.
+These transceivers provide standardized information over the i2c bus at
+specific pages.
 .Ss Supported Standards
 .Bl -tag -width Sy
 .It Sy INF-8074
 The
 .Sy INF-8084
 standard was the original multiple source agreement (MSA) for SFP
-devices.  It proposed the original series of management pages at i2c
-page 0xa0.  This page contained up to 512 bytes, however, only the first
-96 bytes are standardized. Bytes 97 to 127 are reserved for the vendor.
-The remaining bytes are reserved by the specification. The management
-page was subsequently adopted by SFP+ devices.
+devices.
+It proposed the original series of management pages at i2c page 0xa0.
+This page contained up to 512 bytes, however, only the first
+96 bytes are standardized.
+Bytes 97 to 127 are reserved for the vendor.
+The remaining bytes are reserved by the specification.
+The management page was subsequently adopted by SFP+ devices.
 .It Sy SFF-8472
 The
 .Sy SFF-8472
-standard extended the original SFP MSA. This standard added a second i2c
-page at 0xa2, while maintaining the original page at 0xa0. The page at
-0xa0 is now explicitly 256 bytes. The page at 0xa2 is also 256 bytes.
+standard extended the original SFP MSA.
+This standard added a second i2c page at 0xa2, while maintaining the
+original page at 0xa0.
+The page at 0xa0 is now explicitly 256 bytes.
+The page at 0xa2 is also 256 bytes.
 This standard was also adopted for all SFP28 parts, which are commonly
 used in transceivers for 25 Gb/s Ethernet.
 .It Sy SFF-8436
 The
 .Sy SFF-8436
 standard was developed for QSFP+ transceivers, which involve the
-bonding of 4 SFP+ links. QSFP+ is commonly used in the transceivers for
-40 Gb/s Ethernet.  This standard uses i2c page 0xa0 for read-only
-identification purposes. The lower half of the page is used for control,
-while the upper 128 bytes is similar to the
+bonding of 4 SFP+ links.
+QSFP+ is commonly used in the transceivers for 40 Gb/s Ethernet.
+This standard uses i2c page 0xa0 for read-only identification purposes.
+The lower half of the page is used for control, while the upper 128
+bytes is similar to the
 .Sy INF-8084
 and
 .Sy SFF-8472
@@ -120,11 +129,12 @@ standards.
 The
 .Sy SFF-8636
 standard is a common management standard which is shared between both
-SAS and QSFP+ 28 Gb/s transceivers. The latter transceiver is commonly
-found in 100 Gb/s Ethernet. The transceiver's memory map is similar to
-that found in the
+SAS and QSFP+ 28 Gb/s transceivers.
+The latter transceiver is commonly found in 100 Gb/s Ethernet.
+The transceiver's memory map is similar to that found in the
 .Sy SFF-8436
-specification. The identification information is found in the upper 128
+specification.
+The identification information is found in the upper 128
 bytes of page 0xa0, while the lower part of the page is used for
 control, among other purposes.
 .El
@@ -163,26 +173,28 @@ rules:
 .It Sy mct_flags
 The
 .Vt mct_flags
-member is used to negotiate extensions with the driver. MAC will set the
-value of
+member is used to negotiate extensions with the driver.
+MAC will set the value of
 .Vt mct_flags
-to include all of the currently known extensions. The driver should
-intersect this list with the set that they actually support. At this
-time, no such features are defined and the driver should set the member
-to
+to include all of the currently known extensions.
+The driver should intersect this list with the set that they actually
+support.
+At this time, no such features are defined and the driver should set the
+member to
 .Sy 0 .
 .It Sy mct_ntransceivers
 The value of
 .Sy mct_ntransceivers
-indicates that the number of transceivers present in the device. For most
-devices, it is expected that this value will be set to one. However,
-some devices do support multiple transceivers and PHYs that show up
-behind a single logical MAC.
+indicates that the number of transceivers present in the device.
+For most devices, it is expected that this value will be set to one.
+However, some devices do support multiple transceivers and PHYs that
+show up behind a single logical MAC.
 .Pp
 It is expected that this value will not change across the lifetime of
-the device being attached. It is important to remember that this
-represents the total possible number of transceivers in the device, not
-how many are currently present and powered on.
+the device being attached.
+It is important to remember that this represents the total possible
+number of transceivers in the device, not how many are currently present
+and powered on.
 .Pp
 The number of transceivers will influence the
 .Fa id
@@ -190,16 +202,16 @@ argument used in the
 .Fn mct_info
 and
 .Fn mct_read
-entry points. The transceiver IDs will start at zero and go to the value
-of
+entry points.
+The transceiver IDs will start at zero and go to the value of
 .Fa mct_ntransceivers - 1 .
 It is up to the driver to keep the mapping between actual transceivers
 and the transceiver identifiers consistent.
 .It Sy mct_info
 The
 .Fn mct_info
-entry point is used to set basic information about the transceiver. This
-entry point is
+entry point is used to set basic information about the transceiver.
+This entry point is
 .Em required .
 If the device driver cannot implement this entry point, then it should
 not indicate that it supports the capability.
@@ -219,8 +231,8 @@ the functions described in the section
 After successfully calling all of the functions, the driver should
 return
 .Sy 0 .
-Othewrise, it should return the appropriate error number. For a full
-list of error numbers, see
+Othewrise, it should return the appropriate error number.
+For a full list of error numbers, see
 .Xr Intro 2 .
 Common values are:
 .Bl -tag -width Er -offset width
@@ -229,17 +241,18 @@ The transceiver identifier
 .Fa id
 was invalid.
 .It Er ENOTSUP
-This instance of the devices does not support a transceiver. For
-example, a device which sometimes has copper PHYs and therefore this
+This instance of the devices does not support a transceiver.
+For example, a device which sometimes has copper PHYs and therefore this
 instance does not have any PHYs.
 .It Er EIO
-An error occurred while trying to read device registers. For example, an
-FM-aware device had an error.
+An error occurred while trying to read device registers.
+For example, an FM-aware device had an error.
 .El
 .It Sy mct_read
 The
 .Fn mct_read
-function is used to read information from a transceiver's i2c bus. The
+function is used to read information from a transceiver's i2c bus.
+The
 .Fn mct_read
 entry point is an
 .Em optional
@@ -247,8 +260,8 @@ entry point.
 .Pp
 The transceiver should first check the value of
 .Fa id ,
-which indicates which transceiver information is being requested.  See
-the description above of
+which indicates which transceiver information is being requested.
+See the description above of
 .Sy mct_ntransceivers
 for more information on how the IDs are determined.
 .Pp
@@ -264,15 +277,18 @@ with the number of bytes written to the buffer
 .Fa buf .
 .Pp
 If for some reason the driver cannot read all of the requested bytes,
-that is acceptable. Instead it should perform a short read. This may
-occur because the transceiver does not allow reads at a requested region
-or the region is shorter than is common for most devices.
+that is acceptable.
+Instead it should perform a short read.
+This may occur because the transceiver does not allow reads at a
+requested region or the region is shorter than is common for most
+devices.
 .Pp
 Upon successful completion, the driver should ensure that
 .Fa nread
 has been updated and then return
 .Sy 0 .
-Otherwise, the driver should return the appropriate error number. For
+Otherwise, the driver should return the appropriate error number.
+For
 a full list of error numbers, see
 .Xr Intro 2 .
 Common values are:
@@ -280,9 +296,11 @@ Common values are:
 .It Er EINVAL
 The value of
 .Fa id
-represented an invalid transceiver identifier. The transceiver i2c page
+represented an invalid transceiver identifier.
+The transceiver i2c page
 .Fa page
-is not valid for this type of device. The value of
+is not valid for this type of device.
+The value of
 .Fa offset
 is beyond the range supported for this
 .Fa page .
@@ -294,10 +312,12 @@ An error occurred while trying to read the device i2c pages.
 The
 .Fn mct_info
 entry point is the primary required entry point for a device driver
-which supports this capability. The information structure is opaque to
-the device driver. Instead, a series of informational functions is
-available to the device driver to call on the transceiver. The device
-drivers should try to call and fill in as many of these as possible.
+which supports this capability.
+The information structure is opaque to the device driver.
+Instead, a series of informational functions is
+available to the device driver to call on the transceiver.
+The device drivers should try to call and fill in as many of these as
+possible.
 There are two different properties that a driver can set:
 .Bl -enum -offset indent
 .It
@@ -314,37 +334,42 @@ always be called with the value set to
 .Dv B_TRUE .
 .Pp
 Finally, the driver has the ability to provide information about whether
-or not the transceiver is usable or not. A transceiver may be present,
-but not usable, if the hardware and firmware support a limited number of
-transceivers. To set this information, the driver should call
+or not the transceiver is usable or not.
+A transceiver may be present, but not usable, if the hardware and
+firmware support a limited number of transceivers.
+To set this information, the driver should call
 .Xr mac_transceiver_info_set_usable 9F .
 If the transceiver is not present, then the driver should not call this
 function.
 .Ss Opaque Transceivers
 Some devices abstract the nature of the transceiver and do not allow
-direct access to the transceiver. In this case, if the device driver
-still has access to enough information to know if the transceiver is
-at least present, then it should still implement the
+direct access to the transceiver.
+In this case, if the device driver still has access to enough
+information to know if the transceiver is at least present, then it
+should still implement the
 .Fn mct_info
 entry point.
 .Ss Locking and Data Access
 Calls to get information about the transceivers may come at the same
-time as general I/O requests to the device to send or receive data. The
-driver should make sure that reading data from the i2c bus of the
+time as general I/O requests to the device to send or receive data.
+The driver should make sure that reading data from the i2c bus of the
 transceiver does not interfere with the device's functionality in this
-regard. Different locks should be used.
+regard.
+Different locks should be used.
 .Pp
 On some devices, reading from the transceiver's i2c bus might cause a
-disruption of service to the device. For example, on some devices a phy
-reset may be required or come about as a side effect of trying to read
-the device. If any kind of disruption would be caused, then the driver
+disruption of service to the device.
+For example, on some devices a phy reset may be required or come about
+as a side effect of trying to read the device.
+If any kind of disruption would be caused, then the driver
 must not implement the
 .Ft mct_read
 entry point.
 .Sh CONTEXT
 The various callback functions will be called from
 .Sy kernel
-context. These functions will never be called from
+context.
+These functions will never be called from
 .Sy interrupt
 context.
 .Sh SEE ALSO
diff --git a/usr/src/man/man9f/mac_transceiver_info.9f b/usr/src/man/man9f/mac_transceiver_info.9f
index 56d3cdd258..9b04ab3a9d 100644
--- a/usr/src/man/man9f/mac_transceiver_info.9f
+++ b/usr/src/man/man9f/mac_transceiver_info.9f
@@ -33,7 +33,8 @@
 .Fc
 .Sh INTERFACE LEVEL
 .Sy Volatile -
-This interface is still evolving in illumos. API and ABI stability is
+This interface is still evolving in illumos.
+API and ABI stability is
 not guaranteed.
 .Sh PARAMETERS
 .Bl -tag -width Fa
@@ -53,8 +54,8 @@ and
 .Fn mac_transceiver_set_usable
 functions are used to set information about a transceiver as part of the
 .Xr mct_info 9E
-entry point to obtain information about a MAC transceiver. For more
-information and background, see the
+entry point to obtain information about a MAC transceiver.
+For more information and background, see the
 .Sy Transceiver Information Functions
 section of
 .Xr mac_capab_transceiver 9E .
@@ -62,7 +63,8 @@ section of
 The
 .Fn mct_transceiver_set_present
 function sets whether or not the transceiver is present and plugged into
-the system. If the transceiver is not plugged in, then the function
+the system.
+If the transceiver is not plugged in, then the function
 should be called with
 .Fa present set to
 .Dv B_FALSE ,
diff --git a/usr/src/man/man9f/sas_phymap_create.9f b/usr/src/man/man9f/sas_phymap_create.9f
index df29d1327c..97b5515946 100644
--- a/usr/src/man/man9f/sas_phymap_create.9f
+++ b/usr/src/man/man9f/sas_phymap_create.9f
@@ -63,7 +63,8 @@
 .Fc
 .Sh INTERFACE LEVEL
 .Sy Evolving -
-This interface is still evolving in illumos. API and ABI stability is
+This interface is still evolving in illumos.
+API and ABI stability is
 not guaranteed.
 .Sh PARAMETERS
 .Bl -tag -width Fa
@@ -74,7 +75,8 @@ structure.
 .It Fa settle_usec
 A time in microseconds.
 .It Fa mode
-Mode of operation for the phy map. Should be set to
+Mode of operation for the phy map.
+Should be set to
 .Dv PHYMAP_MODE_SIMPLE .
 .It Fa mode_priv
 Drivers should pass
@@ -112,17 +114,18 @@ The
 and
 .Fn sas_phymap_destroy
 functions create and destroy phymaps which are used to manage a set of
-potentially-active SAS phys and the attached devices. For more
-background, see
+potentially-active SAS phys and the attached devices.
+For more background, see
 .Xr phymap 9 .
 If the driver in question is not a SAS HBA or a similar fabric-like
 device, then do not use this interface.
 .Pp
 The phy map maps one or more phys to a logical port-like construct that
-is represented based on the WWNs in question. This logical SAS port has
-a unit address derived from the two WWNs. When the first phy is noted as
-using these WWNs, then the phymap will call any registered callbacks as
-the port is created. If additional phys come online in service of the
+is represented based on the WWNs in question.
+This logical SAS port has a unit address derived from the two WWNs.
+When the first phy is noted as using these WWNs, then the phymap will
+call any registered callbacks as the port is created.
+If additional phys come online in service of the
 same port, then a new port will not be created.
 .Pp
 To facilitate the mapping between a PHY and the corresponding port unit
@@ -134,13 +137,15 @@ functions are available.
 .Pp
 To create a phy map, the driver uses the
 .Fn sas_phymap_create
-function. The resulting phy map will be stored in the
+function.
+The resulting phy map will be stored in the
 .Fa phymapout
-argument. The value in
+argument.
+The value in
 .Fa 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
+changes and consider the resulting system stable.
+Changes will not be reported until after
 .Fa settle_usec
 have passed.
 .Pp
@@ -157,19 +162,22 @@ argument will be passed to both callback functions.
 .Pp
 To destroy a phymap, the driver should call the
 .Fn sas_phymap_destroy
-function. A side effect of this is that all existing entries in the phy
+function.
+A side effect of this is that all existing entries in the phy
 map will be removed and their deactivate callbacks will fire.
 .Ss Callbacks
 The phymap provides a means for receiving callbacks when the addition of
 a phy causes a new logical port to be created or when the phy being
-removed is the last phy that is a member of the port. Unlike with the
+removed is the last phy that is a member of the port.
+Unlike with the
 .Xr tgtmap 9 ,
-there is no system managed driver that is attached with the phymap. For
-the phymap to be useful to drivers, the callbacks should generally be
-registered.
+there is no system managed driver that is attached with the phymap.
+For the phymap to be useful to drivers, the callbacks should generally
+be registered.
 .Pp
 It's important to emphasize that the callbacks do not represent phys,
-but instead the logical port that they are bound to. This is different
+but instead the logical port that they are bound to.
+This is different
 from the
 .Xr tgtmap 9
 and
@@ -183,7 +191,8 @@ functions may not result in anything being created in the system.
 The
 .Fa activate_cb
 callback occurs whenever a new logical port is created because the first
-phy that references that pair of WWNs has been created. The
+phy that references that pair of WWNs has been created.
+The
 .Fa phymap_priv
 argument corresponds to the value passed in the
 .Fn sas_phymap_create
@@ -198,7 +207,8 @@ and
 .Fa remote
 arguments to the
 .Fn sas_phymap_phy_add
-function. If this is being used together with an
+function.
+If this is being used together with an
 .Xr iportmap 9
 then the
 .Fa ua
@@ -206,17 +216,18 @@ should be the name of the added iport.
 .Pp
 The
 .Fa ua_privp
-argument allows for data to be correlated with the unit-address. This
-data is accessible throughout the lifetime of the unit-address through
-the
+argument allows for data to be correlated with the unit-address.
+This data is accessible throughout the lifetime of the unit-address
+through the
 .Xr sas_phymap_lookup_uapriv 9F
 function and is also made available during the deactivate callback.
 .Pp
 The
 .Fa deactivate_cb
 callback occurs when the logical port is being removed, because the last
-associated phy has been removed. The arguments to this are the same as
-to the activate callback, with the exception that the
+associated phy has been removed.
+The arguments to this are the same as to the activate callback, with the
+exception that the
 .Fa ua_priv
 argument is the value that was stored in the
 .Fa ua_privp
@@ -224,15 +235,17 @@ argument of the activate callback.
 .Ss Adding and Removing PHYs
 To add a phy to the system, the driver should call the
 .Fn sas_phymap_phy_add
-function. The
+function.
+The
 .Fa phy
 argument should indicate the phy identifier of the phy that has come up.
 The
 .Fa local
 WWN generally corresponds to the SAS port on the controller, while the
 .Fa remote
-WWN is whatever device is on the other side of the phy. The system
-enforces that a given phy only maps to a single port at any time.
+WWN is whatever device is on the other side of the phy.
+The system enforces that a given phy only maps to a single port at any
+time.
 .Pp
 When a phy goes offline, then the driver should call the
 .Fn sas_phymap_phy_rem
diff --git a/usr/src/man/man9f/sas_phymap_lookup_ua.9f b/usr/src/man/man9f/sas_phymap_lookup_ua.9f
index 12cb35f16d..5255f49632 100644
--- a/usr/src/man/man9f/sas_phymap_lookup_ua.9f
+++ b/usr/src/man/man9f/sas_phymap_lookup_ua.9f
@@ -21,8 +21,8 @@
 .Nm sas_phymap_ua_free ,
 .Nm sas_phymap_uahasphys ,
 .Nm sas_phymap_ua2phys ,
-.Nm sas_phymap_phys_next
-.Nm sas_phymap_phys_free ,
+.Nm sas_phymap_phys_next ,
+.Nm sas_phymap_phys_free
 .Nd SAS phymap utility functions
 .Sh SYNOPSIS
 .In sys/scsi/scsi.h
@@ -66,7 +66,8 @@
 .Fc
 .Sh INTERFACE LEVEL
 .Sy Evolving -
-This interface is still evolving in illumos. API and ABI stability is
+This interface is still evolving in illumos.
+API and ABI stability is
 not guaranteed.
 .Sh PARAMETERS
 .Bl -tag -width Fa
@@ -86,7 +87,8 @@ An opaque structure that represents a collection of phys on a port.
 .El
 .Sh DESCRIPTION
 The functions described here are all utility functions for operating on
-a phymap and the entities it creates.  For more information on phymaps,
+a phymap and the entities it creates.
+ For more information on phymaps,
 see
 .Xr phymap 9
 and
@@ -99,9 +101,11 @@ the tuple of the
 .Fa local
 and
 .Fa remote
-WWN. If a logical port exists for that tuple, then a pointer to its
-system generated unit-address is returned. This string is managed by the
-system and it must not be modified or freed. If it cannot be found, then
+WWN.
+If a logical port exists for that tuple, then a pointer to its
+system generated unit-address is returned.
+This string is managed by the system and it must not be modified or freed.
+If it cannot be found, then
 .Dv NULL
 is returned.
 .Pp
@@ -120,7 +124,8 @@ represented by the unit address specified in
 .Fa ua
 that is a part of the phymap
 .Fa phymap
-has any phys. If phys are found, then the function returns
+has any phys.
+If phys are found, then the function returns
 .Sy 1 .
 .Pp
 The
@@ -130,9 +135,11 @@ function attempts to map a given phy specified by
 to its unit-address in the map
 .Fa phymap .
 This function will allocate memory for the character string, thus it can
-be modified. The caller must call the
+be modified.
+The caller must call the
 .Fa sas_phymap_ua_free
-function to release the memory that was allocated. The
+function to release the memory that was allocated.
+The
 .Fa sas_phymap_ua_free
 function should not be used with the string returned from the
 .Fn sas_phymap_lookup_ua
@@ -147,11 +154,13 @@ in the map
 .Fa phymap .
 This set can be iterated by calling the
 .Fn sas_phyap_phys_next
-function. Each time the function is called, an entry is returned. When
-the value
+function.
+Each time the function is called, an entry is returned.
+When the value
 .Sy -1
-is returned it indicates that the set is empty. Regardless of whether or
-not the set has been iterated over, the caller must call the
+is returned it indicates that the set is empty.
+Regardless of whether or not the set has been iterated over, the caller
+must call the
 .Fn sas_phymap_phys_free
 function to release the memory associated with the set.
 .Sh CONTEXT
@@ -166,8 +175,9 @@ Upon successful completion, the
 .Fn sas_phymap_lookup_ua
 and
 .Fn sas_phymap_phy2ua
-function returns a pointer to the unit-address. If the port or phy could
-not be found or another error occurred, then the function returns
+function returns a pointer to the unit-address.
+If the port or phy could not be found or another error occurred, then
+the function returns
 .Dv NULL .
 .Pp
 Upon successful completion, the
@@ -180,16 +190,16 @@ Upon successful completion, the
 .Fn sas_phymap_uahasphys
 returns
 .Sy 1
-to indicate that the unit-address has phys. If the unit-address
-has no phys, then it returns
+to indicate that the unit-address has phys.
+If the unit-address has no phys, then it returns
 .Sy 0 .
 If an error occurred or the port doesn't exist, then the function returns
 .Sy 0 .
 .Pp
 Upon successful completion, the
 .Fn sas_phymap_ua2phys
-function returns a pointer to an allocated phy set. Otherwise, it
-returns
+function returns a pointer to an allocated phy set.
+Otherwise, it returns
 .Dv NULL .
 .Pp
 The
diff --git a/usr/src/man/man9f/scsi_address_device.9f b/usr/src/man/man9f/scsi_address_device.9f
index 7bbe7b8ed1..f550d5d324 100644
--- a/usr/src/man/man9f/scsi_address_device.9f
+++ b/usr/src/man/man9f/scsi_address_device.9f
@@ -41,7 +41,8 @@
 .Fc
 .Sh INTERFACE LEVEL
 .Sy Evolving -
-This interface is still evolving in illumos. API and ABI stability is
+This interface is still evolving in illumos.
+API and ABI stability is
 not guaranteed.
 .Sh PARAMETERS
 .Bl -tag -width Fa
@@ -58,17 +59,20 @@ A private value that the driver can get and set.
 .El
 .Sh DESCRIPTION
 These functions provide useful services for SCSI HBA drivers that use
-complex addressing. In complex addressing mode, the
+complex addressing.
+In complex addressing mode, the
 .Xr scsi_address 9S
 structure is treated as an opaque structure and is not a simple target
-and LUN. To use these functions, the driver must have enabled complex
-addressing by passing the
+and LUN.
+To use these functions, the driver must have enabled complex addressing
+by passing the
 .Dv SCSI_HBA_ADDR_COMPLEX
 flag into the
 .Fa hba_flags
 argument of the
 .Xr scsi_hba_attach_setup 9F
-function. If the
+function.
+If the
 .Dv SCSI_HBA_ADDR_COMPLEX
 flag was not passed, then the driver must not call the
 .Fn scsi_device_hba_private_get ,
@@ -83,7 +87,8 @@ function maps the
 .Xr scsi_address 9S
 function back to its corresponding
 .Xr scsi_device 9S
-structure. If the
+structure.
+If the
 .Dv SCSI_HBA_ADDR_COMPLEX
 flag has not been set, then the function will return
 .Dv NULL .
@@ -96,18 +101,20 @@ function, allows a driver to set a private data value on the
 .Xr scsi_device 9S
 structure, which it can later retrieve through the
 .Fn scsi_device_hba_private_get
-function. Most drivers will set a value during the
+function.
+Most drivers will set a value during the
 .Xr tran_start 9E
-entry point and then reference the data structure later on. This is
-designed to simplify the management of mapping between driver data
-structures and the corresponding system objects.
+entry point and then reference the data structure later on.
+This is designed to simplify the management of mapping between driver
+data structures and the corresponding system objects.
 .Pp
 The
 .Fn scsi_device_unit_address
 function returns the unit address of the
 .Xr scsi_device 9S
-structure. The returned string should not be modified by the device
-driver. The unit address string comes from values that are passed when
+structure.
+The returned string should not be modified by the device driver.
+The unit address string comes from values that are passed when
 the device is enumerated, generally through an instance of an
 .Xr iport 9 .
 .Sh CONTEXT
@@ -122,7 +129,8 @@ Upon successful completion, the
 .Fn scsi_address_device
 function returns a pointer to the
 .Xr scsi_device 9S
-structure. Otherwise, if an error occurred
+structure.
+Otherwise, if an error occurred
 .Dv NULL
 is returned.
 .Pp
@@ -130,7 +138,8 @@ The
 .Fn scsi_device_hba_private_set
 function returns a data value registered via the
 .Fn scsi_device_hba_private_get
-function. If the
+function.
+If the
 .Fn scsi_device_hba_private_get
 was never called,
 .Dv NULL
diff --git a/usr/src/man/man9f/scsi_hba_attach_setup.9f b/usr/src/man/man9f/scsi_hba_attach_setup.9f
index b713d1e7ba..45a72a06ca 100644
--- a/usr/src/man/man9f/scsi_hba_attach_setup.9f
+++ b/usr/src/man/man9f/scsi_hba_attach_setup.9f
@@ -8,7 +8,7 @@
 .Dt SCSI_HBA_ATTACH_SETUP 9F
 .Os
 .Sh NAME
-.Nm scsi_hba_attach_setup
+.Nm scsi_hba_attach_setup ,
 .Nm scsi_hba_detach
 .Nd SCSI HBA attach and detach routines
 .Sh SYNOPSIS
@@ -37,7 +37,8 @@ Pointer to a
 .Xr scsi_hba_tran 9S
 structure.
 .It Fa hba_flags
-Flag modifiers. The defined flag values are
+Flag modifiers.
+The defined flag values are
 .Dv SCSI_HBA_TRAN_CLONE ,
 .Dv SCSI_HBA_TRAN_SCB ,
 .Dv SCSI_HBA_TRAN_CDB ,
@@ -69,7 +70,8 @@ function uses the
 .Vt dev_bus_ops
 field in the
 .Xr dev_ops 9S
-structure. The HBA driver should initialize this field to
+structure.
+The HBA driver should initialize this field to
 .Dv NULL
 before calling
 .Fn scsi_hba_attach_setup .
@@ -81,13 +83,15 @@ is requested in
 the
 Fa hba_tran
 structure is cloned once for each target that is attached to the
-HBA. The use of this flag is deprecated, drivers should instead use
+HBA.
+The use of this flag is deprecated, drivers should instead use
 .Dv SCSI_HBA_ADDR_COMPLEX
 for per-target data.
 .Pp
 The structure is cloned before the
 .Xr tran_tgt_init 9E
-entry point is called to initialize a target. At all subsequent HBA
+entry point is called to initialize a target.
+At all subsequent HBA
 entry points, including
 .Xr tran_tgt_init 9E ,
 the
@@ -101,9 +105,11 @@ structure, which allows the HBA to use the
 .Vt tran_tgt_private
 field in the
 .Vt scsi_hba_tran_t
-structure to point to per-target data. The HBA should free only the same
+structure to point to per-target data.
+The HBA should free only the same
 .Vt scsi_hba_tran_t
-structure allocated when the HBA detaches. All cloned
+structure allocated when the HBA detaches.
+All cloned
 .Vt scsi_hba_tran_t
 structures that are allocated by the system are freed by the system.
 .Pp
@@ -114,18 +120,21 @@ and
 are only valid
 when
 .Fn tran_setup_pkt
-is used. See
+is used.
+See
 .Xr tran_setup_pkt 9E
 for information on using these flags.
 .Pp
 The flag
 .Dv SCSI_HBA_ADDR_COMPLEX
 indicates to the system that this device handles more complex SCSI
-topologies, such as SAS. When this flag is set, the
+topologies, such as SAS.
+When this flag is set, the
 .Xr scsi_address 9S
-structure becomes opaque. The driver must not check it for the
-traditional target and LUN values. Instead, a target and LUN are
-identified by a unit address which can be retrieved using the
+structure becomes opaque.
+The driver must not check it for the traditional target and LUN values.
+Instead, a target and LUN are identified by a unit address which can be
+retrieved using the
 .Xr scsi_device_unit_address 9F
 function.
 .Pp
@@ -133,20 +142,24 @@ When operating with the flag
 .Dv SCSI_HBA_ADDR COMPLEX ,
 the driver may associate private data with the
 .Xr scsi_device 9S
-structure. This obviates the need and complexity around using
+structure.
+This obviates the need and complexity around using
 .Dv SCSI_HBA_TRAN_CLONE
-flag. To get and set private data, the driver can use the
+flag.
+To get and set private data, the driver can use the
 .Xr scsi_device_hba_private_get 9F
 and
 .Xr scsi_device_hba_private_set 9F
-functions. Notably, the
+functions.
+Notably, the
 .Fn scsi_device_hba_private_set
 function should be used during the
 .Xr tran_tgt_init 9E
-entry point. The
+entry point.
+The
 .Fn scsi_device_hba_private_get
-function should then be used during other SCSI HBA entry points. In
-addition, the
+function should then be used during other SCSI HBA entry points.
+In addition, the
 .Xr scsi_address_device 9F
 function now becomes available to the driver to map between the
 .Xr scsi_device 9S
@@ -159,21 +172,22 @@ The
 flag indicates that the HBA driver will only enumerate direct children
 which are
 .Xr iport 9
-instances. This mode of operation is recommended for device drivers as
-it simplifies the management of discovered devices. This flag is often
-used in tandem with
+instances.
+This mode of operation is recommended for device drivers as
+it simplifies the management of discovered devices.
+This flag is often used in tandem with
 .Dv SCSI_HBA_ADDR_COMPLEX
-and is recommended for all new SAS-based HBA drivers. For more
-information on the management of iports and the use of target maps,
-please see
+and is recommended for all new SAS-based HBA drivers.
+For more information on the management of iports and the use of target
+maps, please see
 .Xr iport 9 .
 .Pp
 The
 .Fn scsi_hba_attach_setup
 function attaches a number of integer-valued properties to
 .Fa dip ,
-unless properties of the same name are already attached to the node. An
-HBA driver should retrieve these configuration parameters via
+unless properties of the same name are already attached to the node.
+An HBA driver should retrieve these configuration parameters via
 .Xr ddi_prop_get_int 9F ,
 and respect any settings for features provided the HBA.
 .Bl -tag -width Sy
@@ -189,7 +203,8 @@ If not set, the HBA should not operate in Command Tagged Queueing mode.
 If not set, the HBA should not operate in parity mode.
 .It Dv SCSI_OPTIONS_QAS
 If not set, the HBA should not make use of the Quick Arbitration Select
-feature. Consult your hardware documentation to determine whether your
+feature.
+Consult your hardware documentation to determine whether your
 machine supports QAS.
 .It Dv SCSI_OPTIONS_FAST
 If not set, the HBA should not operate the bus in FAST SCSI mode.
@@ -211,8 +226,9 @@ If not set, the HBA should not operate the bus in synchronous transfer mode.
 .It Sy scsi-reset-delay
 SCSI bus or device reset recovery time, in milliseconds.
 .It Sy scsi-selection-timeout
-Default SCSI selection phase timeout value, in milliseconds. Please refer to
-individual HBA man pages for any HBA-specific information
+Default SCSI selection phase timeout value, in milliseconds.
+Please refer to individual HBA man pages for any HBA-specific
+information
 .El
 .Ss Fn scsi_hba_detach
 The
diff --git a/usr/src/man/man9f/scsi_hba_iport_exist.9f b/usr/src/man/man9f/scsi_hba_iport_exist.9f
index 496542962d..2f059bc1a7 100644
--- a/usr/src/man/man9f/scsi_hba_iport_exist.9f
+++ b/usr/src/man/man9f/scsi_hba_iport_exist.9f
@@ -31,8 +31,8 @@
 .Fc
 .Sh INTERFACE LEVEL
 .Sy Evolving -
-This interface is still evolving in illumos. API and ABI stability is
-not guaranteed.
+This interface is still evolving in illumos.
+API and ABI stability is not guaranteed.
 .Sh PARAMETERS
 .Bl -tag -width Fa
 .It Fa dip
@@ -58,11 +58,11 @@ The
 .Fn scsi_hba_iport_find
 function attempts to find a child iport and return its
 .Vt dev_info
-structure if it exists. The iport is searched for by its unit address,
-which is passed in the
+structure if it exists.
+The iport is searched for by its unit address, which is passed in the
 .Fa ua
-argument. The unit address for an iport is established when the iport is
-created.
+argument.
+The unit address for an iport is established when the iport is created.
 .Sh CONTEXT
 The
 .Fn scsi_hba_iport_exist
@@ -87,7 +87,8 @@ The
 .Fn scsi_hba_iport_find
 function returns a pointer to the iport's
 .Vt dev_info
-structure, if found. Otherwise,
+structure, if found.
+Otherwise,
 .Dv NULL
 is returned.
 .Sh SEE ALSO
diff --git a/usr/src/man/man9f/scsi_hba_iport_register.9f b/usr/src/man/man9f/scsi_hba_iport_register.9f
index 15459434a0..4f32054d4c 100644
--- a/usr/src/man/man9f/scsi_hba_iport_register.9f
+++ b/usr/src/man/man9f/scsi_hba_iport_register.9f
@@ -26,7 +26,8 @@
 .Fc
 .Sh INTERFACE LEVEL
 .Sy Evolving -
-This interface is still evolving in illumos. API and ABI stability is
+This interface is still evolving in illumos.
+API and ABI stability is
 not guaranteed.
 .Sh PARAMETERS
 .Bl -tag -width Fa
@@ -40,28 +41,29 @@ The name of the iport to add.
 .Sh DESCRIPTION
 The
 .Fn scsi_hba_iport_register
-function is used to create a new iport. For more information on iports
-and their uses, see
+function is used to create a new iport.
+For more information on iports and their uses, see
 .Xr iport 9 .
 This interface is generally used then there are a fixed, static set of
-iports that exist in the system. If the set of iports is dynamic or
-related to phys coming online and offline, then the driver should
-instead consider using the
+iports that exist in the system.
+If the set of iports is dynamic or related to phys coming online and
+offline, then the driver should instead consider using the
 .Xr iportmap 9
 abstraction.
 .Pp
 The iport will be created as a child of the device represented by
 .Fa dip .
-The iport will be bound to the same driver. To distinguish nodes, the
-driver should use the
+The iport will be bound to the same driver.
+To distinguish nodes, the driver should use the
 .Xr scsi_hba_iport_unit_address 9F
 function.
 .Pp
 The name of the iport, specified by
 .Fa port ,
-must be unique for a given parent. The iport will not be created if the
-name is already in use. While names generally are based on unit
-addresses, they may be synthetic names.
+must be unique for a given parent.
+The iport will not be created if the name is already in use.
+While names generally are based on unit addresses, they may be synthetic
+names.
 .Sh CONTEXT
 The
 .Fn scsi_hba_iport_register
diff --git a/usr/src/man/man9f/scsi_hba_iport_unit_address.9f b/usr/src/man/man9f/scsi_hba_iport_unit_address.9f
index a143bbd1eb..94b11d84c2 100644
--- a/usr/src/man/man9f/scsi_hba_iport_unit_address.9f
+++ b/usr/src/man/man9f/scsi_hba_iport_unit_address.9f
@@ -25,7 +25,8 @@
 .Fc
 .Sh INTERFACE LEVEL
 .Sy Evolving -
-This interface is still evolving in illumos. API and ABI stability is
+This interface is still evolving in illumos.
+API and ABI stability is
 not guaranteed.
 .Sh PARAMETERS
 .Bl -tag -width Fa
@@ -37,12 +38,13 @@ structure.
 .Sh DESCRIPTION
 The
 .Fn scsi_hba_iport_unit_address
-function is used to obtain the unit address of an iport. For more
-information on iports, see
+function is used to obtain the unit address of an iport.
+For more information on iports, see
 .Xr iport 9 .
 .Pp
 This function can be used to determine whether or not a device node in
-the tree is an iport. If the device node corresponds to an iport, then
+the tree is an iport.
+If the device node corresponds to an iport, then
 the unit address used when it was created either through
 .Xr scsi_hba_iport_register 9F
 or
@@ -61,7 +63,8 @@ context.
 If
 .Fa dip
 is an iport, then the unit address string the device was registered with
-is returned. Otherwise,
+is returned.
+Otherwise,
 .Dv NULL
 is returned.
 .Sh SEE ALSO
diff --git a/usr/src/man/man9f/scsi_hba_iportmap_create.9f b/usr/src/man/man9f/scsi_hba_iportmap_create.9f
index 258312a994..8c7e127160 100644
--- a/usr/src/man/man9f/scsi_hba_iportmap_create.9f
+++ b/usr/src/man/man9f/scsi_hba_iportmap_create.9f
@@ -46,8 +46,8 @@
 .Fc
 .Sh INTERFACE LEVEL
 .Sy Evolving -
-This interface is still evolving in illumos. API and ABI stability is
-not guaranteed.
+This interface is still evolving in illumos.
+API and ABI stability is not guaranteed.
 .Sh PARAMETERS
 .Bl -tag -width Fa
 .It Fa dip
@@ -74,8 +74,8 @@ The
 .Fn scsi_hba_iportmap_create
 and
 .Fn 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
+functions are used by HBA drivers to create and destroy an iportmap.
+For more information on an iportmap and its purpose, see
 .Xr iportmap 9 .
 .Pp
 The
@@ -83,11 +83,12 @@ The
 and
 .Fa settle_usec
 are both times measured in microseconds that control two different
-properties of the iportmap and how it behaves. The value in
+properties of the iportmap and how it behaves.
+The value in
 .Fa 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
+changes and consider the resulting system stable.
+Changes will not be reported until after
 .Fa settle_usec
 have passed.
 .Fa csync_usec
@@ -111,7 +112,8 @@ and remove iports.
 .Pp
 To destroy the iportmap, drivers should use the
 .Fn scsi_hba_iportmap_destroy
-function. As part of destroying the iportmap, all associated iports will
+function.
+As part of destroying the iportmap, all associated iports will
 be detached from the system by having the driver's
 .Xr detach 9E
 entry point called.
@@ -119,18 +121,21 @@ 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
 .Fn scsi_hba_iportmap_iport_add
-function. The value of
+function.
+The value of
 .Fa 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
+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
 .Fa ua
 to a unique string which is generally the iport's WWN.
 .Pp
 When the corresponding iport needs to be removed, then the driver should
 call the
 .Fn scsi_hba_iportmap_remove
-function. The iport to remove is indicated by the
+function.
+The iport to remove is indicated by the
 .Fa ua
 argument, which should match the value passed into the
 .Fn scsi_hba_iportmap_add
diff --git a/usr/src/man/man9f/scsi_hba_tgtmap_create.9f b/usr/src/man/man9f/scsi_hba_tgtmap_create.9f
index d01239dab5..3f5a393cf1 100644
--- a/usr/src/man/man9f/scsi_hba_tgtmap_create.9f
+++ b/usr/src/man/man9f/scsi_hba_tgtmap_create.9f
@@ -22,7 +22,7 @@
 .Nm scsi_hba_tgtmap_set_end ,
 .Nm scsi_hba_tgtmap_set_flush ,
 .Nm scsi_hba_tgtmap_tgt_add ,
-.Nm scsi_hba_tgtmap_tgt_remove ,
+.Nm scsi_hba_tgtmap_tgt_remove
 .Nd SCSI target map functions
 .Sh SYNOPSIS
 .In sys/scsi/scsi.h
@@ -90,7 +90,8 @@
 .Fc
 .Sh INTERFACE LEVEL
 .Sy Evolving -
-This interface is still evolving in illumos. API and ABI stability is
+This interface is still evolving in illumos.
+API and ABI stability is
 not guaranteed.
 .Sh PARAMETERS
 .Bl -tag -width Fa
@@ -151,15 +152,17 @@ The
 .Fn scsi_hba_tgtmap_create
 and
 .Fn scsi_hba_tgtmap_destroy
-functions are used to create and destroy target maps. A target map is
-used to manage SCSI and SMP (SCSI Management Protocol) devices. For more
-background on target maps, see
+functions are used to create and destroy target maps.
+A target map is used to manage SCSI and SMP (SCSI Management Protocol)
+devices.
+For more background on target maps, see
 .Xr tgtmap 9 .
 .Pp
 To create a target map, the driver should call the
 .Fn scsi_hba_tgtmap_create
-function. Upon successful completion, a pointer to the target map will
-be placed in the
+function.
+Upon successful completion, a pointer to the target map will be placed
+in the
 .Fa tgtmapout
 argument.
 .Pp
@@ -171,12 +174,14 @@ iports.
 The
 .Fa mode
 argument describes how addresses are reported into the target map and
-the functions used to add and remove devices. If
+the functions used to add and remove devices.
+If
 .Fa mode
 is
 .Dv SCSI_TM_FULLSET
 then the driver must always report all the devices that are in the set
-and will be told when the corresponding devices have been removed. See
+and will be told when the corresponding devices have been removed.
+See
 the section
 .Sx Full-Set Reporting
 for more information.
@@ -189,7 +194,8 @@ and use the
 .Fn scsi_hba_tgtmap_tgt_add
 and
 .Fn scsi_hba_tgtmap_tgt_destroy
-functions. See the section
+functions.
+See the section
 .Sx Per-Address Reporting
 for more information.
 .Pp
@@ -198,11 +204,12 @@ The
 and
 .Fa settle_usec
 are both times measured in microseconds that control two different
-properties of the target map and how it behaves. The value in
+properties of the target map and how it behaves.
+The value in
 .Fa 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
+changes and consider the resulting system stable.
+Changes will not be reported until after
 .Fa settle_usec
 have passed.
 .Fa csync_usec
@@ -214,9 +221,9 @@ The
 and
 .Fa deactivate_cb
 arguments are optional function pointers that will be run in the context
-of devices being added and removed from the system. This allows the HBA
-driver to perform any required operations prior to the system attaching
-a target driver such as
+of devices being added and removed from the system.
+This allows the HBA driver to perform any required operations prior to
+the system attaching a target driver such as
 .Xr sd 7D
 or
 .Xr ses 7D
@@ -225,13 +232,15 @@ the removal case.
 .Pp
 To destroy a target map, a caller should use the
 .Fn scsi_hba_tgtmap_destroy
-function. Destroying a target map causes all currently present devices
+function.
+Destroying a target map causes all currently present devices
 to be deactivated, as though they were removed, prior to the
 final destruction of the target map.
 .Ss Callbacks
 Target maps allow for callbacks to be registered and called when
-devices are being added and removed from the system. A driver specifies
-these when the target map is created by passing in function pointers to
+devices are being added and removed from the system.
+A driver specifies these when the target map is created by passing in
+function pointers to
 the
 .Fn activate_cb
 and
@@ -242,17 +251,20 @@ When a new address is registered in a target map and the driver has
 specified a function in the
 .Fa activate_cb
 argument, the driver will eventually have their activation function
-called. This call will be asynchronous with respect to the adding and
+called.
+This call will be asynchronous with respect to the adding and
 removing of entries, regardless of whether the target map is using
-per-address or full-set reporting. This call will occur before any
-driver is bound to the discovered address.
+per-address or full-set reporting.
+This call will occur before any driver is bound to the discovered
+address.
 .Pp
 The
 .Fa tgtmap_priv
 argument will point to the optional, private argument that was passed
 to the
 .Fn scsi_hba_tgtmap_create
-function when the target map was created. The
+function when the target map was created.
+The
 .Fa tgt_addr
 and
 .Fa tgt_type
@@ -265,7 +277,8 @@ functions.
 .Pp
 The
 .Fa tgt_privp
-argument is a modifiable private value. Initially,
+argument is a modifiable private value.
+Initially,
 .Fa tgt_privp
 points to the value passed in as
 .Fa tgt_priv
@@ -273,14 +286,16 @@ to either the
 .Fn scsi_hba_tgtmap_set_add
 or
 .Fn scsi_hba_tgtmap_tgt_add
-functions. The driver may change the value as needed. It will receive
-the value stored in
+functions.
+The driver may change the value as needed.
+It will receive the value stored in
 .Fa tgt_privp
 during the deactivate callback.
 .Pp
 When a target map has been updated to indicate that a device has been
 removed, then the driver will receive a deactivation callback if it
-registered one. The deactivate callback will occur after a driver has
+registered one.
+The deactivate callback will occur after a driver has
 been detached from the corresponding device.
 .Pp
 The
@@ -289,7 +304,8 @@ The
 and
 .Fa type
 arguments to the callback function are the same as for the activate
-case. The
+case.
+The
 .Fa tgt_priv
 pointer will be set to the value that was passed when the device was
 added and will reflect any updates made during an activate callback, if
@@ -298,13 +314,14 @@ present.
 The
 .Fa deact
 argument gives the driver some amount of information as to why device
-was being removed. The deactivation reason provides the driver
+was being removed.
+The deactivation reason provides the driver
 more information about why the address was being removed from the target
 map which can be useful in the cases that it itself did not issue it.
 .Pp
 The return value indicates whether or not some amount of rediscovery of
-the address is desired or not. This is only meaningful in the case where
-the
+the address is desired or not.
+This is only meaningful in the case where the
 .Fa deact
 argument was
 .Dv SCSI_TGT_DEACT_RSN_CFG_FAIL .
@@ -318,24 +335,26 @@ Note, even if the driver returns
 .Dv B_TRUE ,
 no action may be taken by the system.
 .Ss Full-Set Reporting
-Full-Set reporting is one way of managing a target map. In full-set
-reporting, whenever an update is being made, the entire data set is
-reported to the target map. The target map then determines which
+Full-Set reporting is one way of managing a target map.
+In full-set reporting, whenever an update is being made, the entire data
+set is reported to the target map.
+The target map then determines which
 addresses are new, which have been removed, and which have stayed the
-same and updates the system state appropriately. If devices have been
-added or removed from the system, then any activate and deactivate
-endpoints will be called.
+same and updates the system state appropriately.
+If devices have been added or removed from the system, then any activate
+and deactivate endpoints will be called.
 .Pp
 To begin a new report, the driver should call the
 .Fn scsi_hba_tgtmap_set_begin
-function. Once the report has begun, the driver should add devices by
-calling the
+function.
+Once the report has begun, the driver should add devices by calling the
 .Fn scsi_hba_tgtmap_set_add
-function. Once all devices have been added, the driver should call the
+function.
+Once all devices have been added, the driver should call the
 .Fn scsi_hba_tgtmap_set_end
-function to indicate that the target map processing has ended. If driver
-wishes to discard a report that has begun, but not yet terminated, then
-the driver should call the
+function to indicate that the target map processing has ended.
+If driver wishes to discard a report that has begun, but not yet
+terminated, then the driver should call the
 .Fn scsi_hba_tgtmap_set_flush
 function.
 .Pp
@@ -343,9 +362,10 @@ When adding entries, the driver should indicate the address of the
 device in
 .Fa tgt_addr .
 This will generally be a world wide number (WWN) in a unit-addressable
-form. However, the driver may use its own synthetic numbering. This
-address will be passed to the activate callbacks and will also be used
-as the address of the
+form.
+However, the driver may use its own synthetic numbering.
+This address will be passed to the activate callbacks and will also be
+used as the address of the
 .Xr scsi_device 9S
 in the
 .Xr tran_start 9E
@@ -353,10 +373,10 @@ entry point.
 .Pp
 The
 .Fa type
-argument indicates how the kernel will interpret the type of device. At
-this time, devices are broken into two broad categories. Things which
-are some kind of SCSI device, whether parallel, SCSI, SATA behind a
-SATL, SES, etc. should use the type
+argument indicates how the kernel will interpret the type of device.
+At this time, devices are broken into two broad categories.
+Things which are some kind of SCSI device, whether parallel, SCSI, SATA
+behind a SATL, SES, etc. should use the type
 .Dv SCSI_TGT_SCSI_DEVICE .
 The other group,
 .Dv SCSI_TGT_SMP_DEVICE ,
@@ -375,12 +395,14 @@ cannot drop entries.
 .Pp
 To add a new device, the driver should call the
 .Fa scsi_hba_tgtmap_tgt_add
-function. The
+function.
+The
 .Fa tgt_addr
 and
 .Fa type
 arguments describe the address and what kind of device the address
-corresponds to. For more information, see the previous section,
+corresponds to.
+For more information, see the previous section,
 .Sx Full-Address Reporting .
 The
 .Fa tgt_priv
@@ -432,8 +454,8 @@ functions may be called from
 .Sy user
 or
 .Sy kernel
-context. It is recommended that device drivers do not call these
-functions from
+context.
+It is recommended that device drivers do not call these functions from
 .Sy interrupt
 context and instead should schedule deferred work with a task queue
 or with
diff --git a/usr/src/man/man9f/scsi_wwnstr_to_wwn.9f b/usr/src/man/man9f/scsi_wwnstr_to_wwn.9f
index d8d3ea4ed4..3ff8694050 100644
--- a/usr/src/man/man9f/scsi_wwnstr_to_wwn.9f
+++ b/usr/src/man/man9f/scsi_wwnstr_to_wwn.9f
@@ -38,8 +38,8 @@
 .Fc
 .Sh INTERFACE LEVEL
 .Sy Evolving -
-This interface is still evolving in illumos. API and ABI stability is
-not guaranteed.
+This interface is still evolving in illumos.
+API and ABI stability is not guaranteed.
 .Sh PARAMETERS
 .Bl -tag -width Fa
 .It Fa wwn
@@ -61,20 +61,23 @@ functions convert an 8-byte world wide number to and from a string
 representation.
 .Pp
 World wide numbers are unique identifiers that are used in storage
-technologies, particularly ATA, SAS, and FC. The format of a WWN is
-defined by the IEEE and generally come in 8 and 16 byte forms. These
-interfaces only operate on the 8 byte forms.
+technologies, particularly ATA, SAS, and FC.
+The format of a WWN is defined by the IEEE and generally come in 8 and
+16 byte forms.
+These interfaces only operate on the 8 byte forms.
 .Pp
 When the WWN is represented as a string, it is represented as a 16
-character hexadecimal string. This character string may either use
-uppercase or lowercase hexadecimal characters. The character string may
-be preceded by a
+character hexadecimal string.
+This character string may either use uppercase or lowercase hexadecimal
+characters.
+The character string may be preceded by a
 .Sq w
-character. When this is present, this is called the
+character.
+When this is present, this is called the
 .Em unit-address form .
 If the string is not 16 ASCII character long or 17, when using the
-unit-address form, the string is considered invalid. The following
-macros are provided to help deal with these lengths:
+unit-address form, the string is considered invalid.
+The following macros are provided to help deal with these lengths:
 .Bl -tag -width Dv
 .It Dv SCSI_WWN_STRLEN
 The number of bytes, excluding a terminating nul character, for a world
@@ -91,8 +94,9 @@ The
 .Fn scsi_wwnstr_to_wwn
 function parses the string form of the WWN
 .Fa wwnstr
-and converts it to a 64-bit representation. The string form may either
-be in unit-address form or not. The string must have a nul terminator.
+and converts it to a 64-bit representation.
+The string form may either be in unit-address form or not.
+The string must have a nul terminator.
 If the string is successfully parsed, the world wide number is stored in
 .Fa wwnp .
 .Pp
@@ -100,7 +104,8 @@ The
 .Fn scsi_wwn_to_wwnstr
 converts the world wide number in
 .Fa wwn
-into a human-readable string as described above. If the
+into a human-readable string as described above.
+If the
 .Fa ua_form
 is non-zero then the unit-address form is used and a leading
 .Sq w
@@ -110,9 +115,11 @@ If the
 .Fa wwnstr
 argument is supplied by the user, then it must be large enough to
 contain both the string form of the world wide number and a nul
-character. The
+character.
+The
 .Dv SCSI_WWN_BUFLEN
-macro is recommended. It will always ensure that a buffer is large
+macro is recommended.
+It will always ensure that a buffer is large
 enough to hold any supported string representation of a world wide
 number.
 .Pp
@@ -121,9 +128,10 @@ If the
 argument is instead
 .Dv NULL ,
 then a character string of sufficient size will be allocated by the
-system. Note, this allocation will block until memory is available. If
-memory is allocated in this way, then the caller should free this memory
-with the
+system.
+Note, this allocation will block until memory is available.
+If memory is allocated in this way, then the caller should free this
+memory with the
 .Fn scsi_free_wwnstr
 function.
 .Sh CONTEXT
@@ -145,7 +153,8 @@ function returns
 .Dv DDI_SUCCESS
 and fills in
 .Fa wwnp
-with the WWN. Otherwise,
+with the WWN.
+Otherwise,
 .Dv DDI_FAILURE
 is returned, indicating an invalid argument or a malformed string in
 .Fa wwnstr .
diff --git a/usr/src/man/man9s/scsi_address.9s b/usr/src/man/man9s/scsi_address.9s
index c28f7edcbd..65fc9a017f 100644
--- a/usr/src/man/man9s/scsi_address.9s
+++ b/usr/src/man/man9s/scsi_address.9s
@@ -18,9 +18,10 @@ A
 .Vt scsi_address
 structure defines the addressing components for a
 .Sy SCSI
-target device. The address of the target device is separated into
-two components: target number and logical unit number. The two addressing
-components are used to uniquely identify any type of
+target device.
+The address of the target device is separated into two components:
+target number and logical unit number.
+The two addressing components are used to uniquely identify any type of
 .Sy SCSI
 device; however, most devices can be addressed with the target component of the
 address.
@@ -45,10 +46,10 @@ in the
 .Fa hba_flags
 argument to
 .Xr scsi_hba_attach_setup 9F .
-When the flag is set, this structure must be treated as opaque. Instead
-of storing a traditional target and LUN, the address is treated as the
-string form of a unit address. In addition, rather than storing a
-pointer to the
+When the flag is set, this structure must be treated as opaque.
+Instead of storing a traditional target and LUN, the address is treated
+as the string form of a unit address.
+In addition, rather than storing a pointer to the
 .Xr scsi_hba_tran 9S
 structure, the address structure can store any arbitrary pointer through
 the
@@ -67,7 +68,8 @@ uchar_t           a_lun;        /* SCSI logical unit */
 is a pointer to the controlling
 .Sy HBA 's
 transport vector
-structure. The
+structure.
+The
 .Sy SCSA
 interface uses this field to pass any transport
 requests from the
@@ -84,8 +86,8 @@ address
 .Fa a_lun
 is the logical unit component of the
 .Sy SCSI
-address. The
-logical unit is used to further distinguish a
+address.
+The logical unit is used to further distinguish a
 .Sy SCSI
 target device that
 supports multiple logical units from one that does not.