svn commit: r236773 - stable/9/share/man/man4

[Warren Block]

Author: wblock (doc committer)
Date: Sat Jun  9 01:41:41 2012
New Revision: 236773
URL: http://svn.freebsd.org/changeset/base/236773

Log:
  MFC r236122,r236595:
  
  Wording corrections and simplifications.
  
  Approved by:	gjb (mentor)

Modified:
  stable/9/share/man/man4/vlan.4
Directory Properties:
  stable/9/share/man/man4/   (props changed)

Modified: stable/9/share/man/man4/vlan.4
==============================================================================
--- stable/9/share/man/man4/vlan.4	Sat Jun  9 00:37:26 2012	(r236772)
+++ stable/9/share/man/man4/vlan.4	Sat Jun  9 01:41:41 2012	(r236773)
@@ -25,7 +25,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd October 25, 2011
+.Dd June 4, 2012
 .Dt VLAN 4
 .Os
 .Sh NAME
@@ -33,7 +33,7 @@
 .Nd "IEEE 802.1Q VLAN network interface"
 .Sh SYNOPSIS
 To compile this driver into the kernel,
-place the following lines in your
+place the following line in your
 kernel configuration file:
 .Bd -ragged -offset indent
 .Cd "device vlan"
@@ -79,16 +79,16 @@ to a properly configured switch port.
 The VLAN tag should match one of those set up in the switched
 network.
 .Pp
-Initially
 .Nm
-assumes the same minimum length for tagged and untagged frames.
-This mode is selected by the
+initially assumes the same minimum length for tagged and untagged frames.
+This mode is selected by setting the
 .Xr sysctl 8
 variable
 .Va net.link.vlan.soft_pad
-set to 0 (default).
-However, there are network devices that fail to adjust frame length,
-should it fall below the allowed minimum due to untagging.
+to 0
+.Pq default .
+However, there are network devices that fail to adjust frame length
+when it falls below the allowed minimum due to untagging.
 Such devices should be able to interoperate with
 .Nm
 after changing the value of
@@ -97,7 +97,7 @@ to 1.
 In the latter mode,
 .Nm
 will pad short frames before tagging them
-so that their length stays not less than the minimum value
+so that their length is not less than the minimum value
 after untagging by the non-compliant devices.
 .Sh HARDWARE
 The
@@ -111,7 +111,7 @@ receive and transmit long frames (up to 
 header and FCS).
 The capabilities may be user-controlled by the respective parameters to
 .Xr ifconfig 8 ,
-.Cm vlanhwtag
+.Cm vlanhwtag ,
 and
 .Cm vlanmtu .
 However, a physical interface is not obliged to react to them:
@@ -119,8 +119,8 @@ It may have either capability enabled pe
 a way to turn it off.
 The whole issue is very specific to a particular device and its driver.
 .Pp
-By now, the list of physical interfaces able of full VLAN processing
-in the hardware is limited to the following devices:
+At present, these devices are capable of full VLAN processing
+in hardware:
 .Xr ae 4 ,
 .Xr age 4 ,
 .Xr alc 4 ,
@@ -146,11 +146,10 @@ in the hardware is limited to the follow
 and
 .Xr vge 4 .
 .Pp
-The rest of the Ethernet interfaces can run
-VLANs using software emulation in the
+Other Ethernet interfaces can run VLANs using software emulation in the
 .Nm
 driver.
-However, some of them lack the capability
+However, some lack the capability
 of transmitting and receiving long frames.
 Assigning such an interface as the parent to
 .Nm
@@ -163,9 +162,8 @@ connectivity problems due to massive, in
 .Xr icmp 4
 filtering that breaks the Path MTU Discovery mechanism.
 .Pp
-The following interfaces support long frames for
-.Nm
-natively:
+These interfaces natively support long frames for
+.Nm :
 .Xr axe 4 ,
 .Xr bfe 4 ,
 .Xr cas 4 ,
@@ -198,7 +196,7 @@ for
 use and calculates the appropriate frame MTU based on the
 capabilities of the parent interface.
 Some other interfaces not listed above may handle long frames,
-but they do not advertise this ability of theirs.
+but they do not advertise this ability.
 The MTU setting on
 .Nm
 can be corrected manually if used in conjunction with such a parent interface.