Reflow docs to 79 columns

* This whitespace-only patch reflows the docs (mostly) to 79 columns,
  except for unbreakable links.
* The glossary also had a missing newline at the end of the file.

Change-Id: I8a6c741555de5ed62990fbb2c034651f73327784
Signed-off-by: Jan Gutter <jan.gutter@netronome.com>

HACKING.rst

@@ -1,4 +1,5 @@
 os_vif Style Commandments
 =========================
 
-Read the OpenStack Style Commandments https://docs.openstack.org/hacking/latest/
+Read the OpenStack Style Commandments
+https://docs.openstack.org/hacking/latest/

doc/source/reference/glossary.rst

@@ -207,4 +207,4 @@ Glossary
 
      Refer to this `article by Scott Lowe`__ for more information.
 
-     __ http://blog.scottlowe.org/2009/12/02/what-is-sr-iov/
+     __ http://blog.scottlowe.org/2009/12/02/what-is-sr-iov/

doc/source/user/host-info.rst

@@ -2,75 +2,63 @@
 Host Information
 ================
 
-To enable negotiation of features between a service host
+To enable negotiation of features between a service host (typically a compute
-(typically a compute node) and the network provider host,
+node) and the network provider host, os-vif exposes some objects that describe
-os-vif exposes some objects that describe the host running
+the host running the plugins.
-the plugins.
 
 Host Information Objects
 ========================
 
-The following objects encode the information about the
+The following objects encode the information about the service host.
-service host.
 
 HostInfo
 --------
 
-This class provides information about the host as a whole.
+This class provides information about the host as a whole. This currently means
-This currently means a list of plugins installed on the
+a list of plugins installed on the host. In the future this may include further
-host. In the future this may include further information
+information about the host OS state.
-about the host OS state.
 
 HostPluginInfo
 --------------
 
-This class provides information about the capabilities of
+This class provides information about the capabilities of a single os-vif
-a single os-vif plugin implementation that is installed
+plugin implementation that is installed on the host. This currently means a
-on the host. This currently means a list of VIF objects
+list of VIF objects that the plugin is capable of consuming. In the future this
-that the plugin is capable of consuming. In the future
+may include further information about resources on the host that the plugin
-this may include further information about resources on
+can/will utilize. While many plugins will only ever support a single VIF
-the host that the plugin can/will utilize. While many
+object, it is permitted to support multiple different VIF objects. An example
-plugins will only ever support a single VIF object, it
+would be openvswitch which can use the same underlying host network
-is permitted to support multiple different VIF objects.
+functionality to configure a VM in several different ways.
-An example would be openvswitch which can use the same
-underlying host network functionality to configure a VM
-in several different ways.
 
 HostVIFInfo
 -----------
 
-This class provides information on a single VIF object that
+This class provides information on a single VIF object that is supported by a
-is supported by a plugin. This will include the versioned
+plugin. This will include the versioned object name and the minimum and maximum
-object name and the minimum and maximum versions of the
+versions of the object that can be consumed.
-object that can be consumed.
-
-It is the responsibility of the network provider to ensure
-that it only sends back a serialized VIF object that satisfies
-the minimum and maximum version constraints indicated by the
-plugin. Objects outside of this version range will be rejected
-with a fatal error.
 
+It is the responsibility of the network provider to ensure that it only sends
+back a serialized VIF object that satisfies the minimum and maximum version
+constraints indicated by the plugin. Objects outside of this version range will
+be rejected with a fatal error.
 
 Negotiating networking
 ======================
 
-When a service host wants to create a network port, it will
+When a service host wants to create a network port, it will first populate an
-first populate an instance of the HostInfo class, to describe
+instance of the HostInfo class, to describe all the plugins installed on the
-all the plugins installed on the host. It will then serialize
+host. It will then serialize this class to JSON and send it to the network
-this class to JSON and send it to the network manager host.
+manager host. The network manager host will deserialize it back into a HostInfo
-The network manager host will deserialize it back into a
+object. This can then be passed down into the network driver which can use it
-HostInfo object. This can then be passed down into the network
+to decide how to configure the network port.
-driver which can use it to decide how to configure the network
-port.
 
-If the os-vif version installed on the network host is older
+If the os-vif version installed on the network host is older than that on the
-than that on the service host, it may not be able to deserialize
+service host, it may not be able to deserialize the HostInfo class. In this
-the HostInfo class. In this case it should reply with an error
+case it should reply with an error to the service host. The error message
-to the service host. The error message should report the maximum
+should report the maximum version of the HostInfo class that is supported. the
-version of the HostInfo class that is supported. the service
+service host should then backlevel its HostInfo object to that version before
-host should then backlevel its HostInfo object to that version
+serializing it and re-trying the port creation request.
-before serializing it and re-trying the port creation request.
 
-The mechanism or transport for passing the plugin information
+The mechanism or transport for passing the plugin information between the
-between the network and service hosts is left undefined. It is
+network and service hosts is left undefined. It is upto the user of os-vif to
-upto the user of os-vif to decide upon the appropriate approach.
+decide upon the appropriate approach.

doc/source/user/plugins/linux-bridge.rst

@@ -3,8 +3,8 @@ Linux Bridge
 ============
 
 The Linux Bridge plugin, ``vif_plug_linux_bridge``, is an *os-vif* VIF plugin
-for the Linux Bridge network backend. It is one of three plugins provided as part
+for the Linux Bridge network backend. It is one of three plugins provided as
-of *os-vif* itself, the others being :doc:`ovs` and :doc:`noop`.
+part of *os-vif* itself, the others being :doc:`ovs` and :doc:`noop`.
 
 Supported VIF Types
 -------------------

doc/source/user/vif-types.rst

@@ -73,7 +73,8 @@ VIFHostDevice
 -------------
 
 This class provides a way to pass a physical device to the guest.  Either an
-entire physical device, or an SR-IOV PCI device virtual function, are permitted.
+entire physical device, or an SR-IOV PCI device virtual function, are
+permitted.
 
 .. _vif-nesteddpdk:
 
@@ -116,8 +117,8 @@ device supporting the :term:`802.1Qbh` spec.
 VIFPortProfileFPOpenVSwitch
 ---------------------------
 
-This profile provides the metadata required to associate a fast path :term:`vhost-user`
+This profile provides the metadata required to associate a fast path
-VIF with an :term:`Open vSwitch` port.
+:term:`vhost-user` VIF with an :term:`Open vSwitch` port.
 
 VIFPortProfileOVSRepresentor
 ----------------------------