[ovs-dev,ovn,4/4] Documentation: Update 'internals' to reflect OVN split.
diff mbox series

Message ID 20190925163400.1171-4-blp@ovn.org
State New
Headers show
Series
  • [ovs-dev,ovn,1/4] configure: Improve checks for OVS source and build directories.
Related show

Commit Message

Ben Pfaff Sept. 25, 2019, 4:34 p.m. UTC
This is a start and it should be generally and improvement, but further
improvements are certainly possible.

Signed-off-by: Ben Pfaff <blp@ovn.org>
---
 Documentation/automake.mk                     |   1 -
 Documentation/index.rst                       |   3 +-
 Documentation/internals/bugs.rst              |  21 +-
 .../contributing/backporting-patches.rst      | 127 +-----------
 .../contributing/coding-style-windows.rst     | 183 ------------------
 .../internals/contributing/coding-style.rst   |  16 +-
 .../contributing/documentation-style.rst      |  16 +-
 .../internals/contributing/index.rst          |   9 +-
 .../contributing/submitting-patches.rst       |  43 ++--
 Documentation/internals/documentation.rst     |  20 +-
 Documentation/internals/index.rst             |   8 +-
 Documentation/internals/mailing-lists.rst     |  29 +--
 Documentation/internals/patchwork.rst         |  10 +-
 Documentation/internals/release-process.rst   |  28 +--
 Documentation/internals/security.rst          |  63 +++---
 manpages.mk                                   |  98 ----------
 16 files changed, 114 insertions(+), 561 deletions(-)
 delete mode 100644 Documentation/internals/contributing/coding-style-windows.rst

Patch
diff mbox series

diff --git a/Documentation/automake.mk b/Documentation/automake.mk
index ff376fd831f0..5968d6941561 100644
--- a/Documentation/automake.mk
+++ b/Documentation/automake.mk
@@ -51,7 +51,6 @@  DOC_SOURCE = \
 	Documentation/internals/contributing/index.rst \
 	Documentation/internals/contributing/backporting-patches.rst \
 	Documentation/internals/contributing/coding-style.rst \
-	Documentation/internals/contributing/coding-style-windows.rst \
 	Documentation/internals/contributing/documentation-style.rst \
 	Documentation/internals/contributing/libopenvswitch-abi.rst \
 	Documentation/internals/contributing/submitting-patches.rst \
diff --git a/Documentation/index.rst b/Documentation/index.rst
index 290c0abdd0ad..c0c6c374de17 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -82,8 +82,7 @@  Learn more about the Open vSwitch project and about how you can contribute:
 
 - **Contributing:** :doc:`internals/contributing/submitting-patches` |
   :doc:`internals/contributing/backporting-patches` |
-  :doc:`internals/contributing/coding-style` |
-  :doc:`internals/contributing/coding-style-windows`
+  :doc:`internals/contributing/coding-style`
 
 - **Maintaining:** :doc:`internals/maintainers` |
   :doc:`internals/committer-responsibilities` |
diff --git a/Documentation/internals/bugs.rst b/Documentation/internals/bugs.rst
index c2bcceeb295d..c4c3f86166bc 100644
--- a/Documentation/internals/bugs.rst
+++ b/Documentation/internals/bugs.rst
@@ -21,12 +21,12 @@ 
 
       Avoid deeper levels because they do not render well.
 
-==============================
-Reporting Bugs in Open vSwitch
-==============================
+=====================
+Reporting Bugs in OVN
+=====================
 
 We are eager to hear from users about problems that they have encountered with
-Open vSwitch. This file documents how best to report bugs so as to ensure that
+OVN. This file documents how best to report bugs so as to ensure that
 they can be fixed as quickly as possible.
 
 Please report bugs by sending email to bugs@openvswitch.org.
@@ -43,7 +43,7 @@  The most important parts of your bug report are the following:
 
 Please also include the following information:
 
-- The Open vSwitch version number (as output by ``ovs-vswitchd --version``).
+- The OVN version number (as output by ``ovn-controller --version``).
 
 - The Git commit number (as output by ``git rev-parse HEAD``), if you built
   from a Git snapshot.
@@ -55,16 +55,7 @@  The following are also handy sometimes:
 - The kernel version on which Open vSwitch is running (from ``/proc/version``)
   and the distribution and version number of your OS (e.g. "Centos 5.0").
 
-- The contents of the vswitchd configuration database (usually
-  ``/etc/openvswitch/conf.db``).
-
-- The output of ``ovs-dpctl show``.
-
-- If you have Open vSwitch configured to connect to an OpenFlow
-  controller, the output of ``ovs-ofctl show <bridge>`` for each
-  ``<bridge>`` configured in the vswitchd configuration database.
-
-- A fix or workaround, if you have one.
+- The contents of the northbound database.
 
 - Any other information that you think might be relevant.
 
diff --git a/Documentation/internals/contributing/backporting-patches.rst b/Documentation/internals/contributing/backporting-patches.rst
index 3e6f00459835..b10c9d7b0fb2 100644
--- a/Documentation/internals/contributing/backporting-patches.rst
+++ b/Documentation/internals/contributing/backporting-patches.rst
@@ -30,11 +30,11 @@  Backporting patches
 .. note::
 
     This is an advanced topic for developers and maintainers. Readers should
-    familiarize themselves with building and running Open vSwitch, with the git
-    tool, and with the Open vSwitch patch submission process.
+    familiarize themselves with building and running OVN, with the git
+    tool, and with the OVN patch submission process.
 
 The backporting of patches from one git tree to another takes multiple forms
-within Open vSwitch, but is broadly applied in the following fashion:
+within OVN, but is broadly applied in the following fashion:
 
 - Contributors submit their proposed changes to the latest development branch
 - Contributors and maintainers provide feedback on the patches
@@ -42,29 +42,18 @@  within Open vSwitch, but is broadly applied in the following fashion:
   development branch.
 - Maintainers backport changes from a development branch to release branches.
 
-With regards to Open vSwitch user space code and code that does not comprise
+With regards to OVN user space code and code that does not comprise
 the Linux datapath and compat code, the development branch is `master` in the
-Open vSwitch repository. Patches are applied first to this branch, then to the
+OVN repository. Patches are applied first to this branch, then to the
 most recent `branch-X.Y`, then earlier `branch-X.Z`, and so on. The most common
 kind of patch in this category is a bugfix which affects master and other
 branches.
 
-For Linux datapath code, the primary development branch is in the `net-next`_
-tree as described in the section below, and patch discussion occurs on the
-`netdev`__ mailing list. Patches are first applied to the upstream branch by the
-networking maintainer, then the contributor backports the patch to the Open
-vSwitch `master` development branch. Patches in this category may include
-features which have been applied upstream, or bugfixes to the Open vSwitch
-datapath code. For bugfixes, the patches subsequently follow the regular Open
-vSwitch process as described above to reach older branches.
-
-__ http://vger.kernel.org/vger-lists.html#netdev
-
 Changes to userspace components
 -------------------------------
 
 Patches which are fixing bugs should be considered for backporting from
-`master` to release branches. Open vSwitch contributors submit their patches
+`master` to release branches. OVN contributors submit their patches
 targeted to the `master` branch, using the ``Fixes`` tag described in
 :doc:`submitting-patches`. The maintainer first applies the patch to `master`,
 then backports the patch to each older affected tree, as far back as it goes or
@@ -86,112 +75,10 @@  not a trivial cherry-pick, then the maintainer may opt to submit the backport
 for the older branch on the mailing list for further review. This should be done
 in the same manner as described above.
 
-Changes to Linux kernel components
-----------------------------------
-
-The Linux kernel components in Open vSwitch go through initial review in the
-upstream Linux netdev community before they go into the Open vSwitch tree. As
-such, backports from upstream to the Open vSwitch tree may include bugfixes or
-new features. The `netdev-FAQ`_ describes the general process for merging
-patches to the upstream Linux tree.
-
-To keep track of the changes which are made upstream against the changes which
-have been backported to the Open vSwitch tree, backports should be done in the
-order that they are applied to the upstream `net-next`_ tree. For example, if
-the git history in ``linux/net/openvswitch/`` in the `net-next` tree lists
-patches A, B and C that were applied (in that order), then the backports of
-these patches to ``openvswitch/datapath/`` should be done submitted in the
-order A, B, then C.
-
-Patches that are proposed against the Open vSwitch tree, including backports,
-should follow the guidelines described in :doc:`submitting-patches`. Ideally,
-a series which backports new functionality would also include a series of
-patches for the userspace components which show how to use the new
-functionality, and include tests to validate the behaviour. However, in the
-interests of keeping the Open vSwitch tree in sync with upstream `net-next`,
-contributors may send Open vSwitch kernel module changes independently of
-userspace changes.
-
-.. _netdev-faq: https://www.kernel.org/doc/Documentation/networking/netdev-FAQ.txt
-.. _net-next: http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git
-
-How to backport kernel patches
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-First, the patch should be submitted upstream to `netdev`. When the patch has
-been applied to `net-next`, it is ready to be backported. Starting from the
-Linux tree, use ``git format-patch`` to format each patch that should be
-backported. For each of these patches, they may only include changes to
-``linux/net/openvswitch/``, or they may include changes to other directories.
-Depending on which files the patch touches, the backport may be easier or more
-difficult to undertake.
-
-Start by formatting the relevant patches from the Linux tree. For example, to
-format the last 5 patches to ``net/openvswitch``, going back from OVS commit
-``1234c0ffee5``, placing them into ``/tmp/``:
-
-::
-
-    $ git format-patch -5 1234c0ffee5 net/openvswitch/ -o /tmp
-
-Next, change into the Open vSwitch directory and apply the patch:
-
-::
-
-    $ git am -p3 --reject --directory=datapath/ <patch>
-
-If this is successful, proceed to the next patch:
-
-::
-
-    $ git am --continue
-
-If this is unsuccessful, the above command applies all changes that it can
-to the working tree, and leaves rejected hunks in corresponding \*.rej
-files. Proceed by using ``git diff`` to identify the changes, and edit the
-files so that the hunk matches what the file looks like when the
-corresponding commit is checked out in the linux tree. When all hunks are
-fixed, add the files to the index using ``git add``.
-
-
-If the patch only changes filepaths under ``linux/net/openvswitch``, then most
-likely the patch is fully backported. At this point, review the patch's changes
-and compare with the latest upstream code for the modified functions.
-Occasionally, there may be bugs introduced in a particular patch which were
-fixed in a later patch upstream. To prevent breakage in the OVS tree, consider
-rolling later bugfixes into the current patch - particularly if they are small,
-clear bugfixes in the logic of this patch. Then proceed to the next patch using
-``git am --continue``. If you made any changes to the patch compared with the
-original version, describe the changes in the commit message.
-
-If the changes affects other paths, then you may also need to backport function
-definitions from the upstream tree into the ``datapath/linux/compat``
-directory. First, attempt to compile the datapath. If this is successful, then
-most likely there is no further work required. As per the previous paragraph,
-consider reviewing and backporting any minor fixes to this code if applicable,
-then proceed to the next patch using ``git am --continue``.
-
-If compilation fails, the compiler will show which functions are missing or
-broken. Typically this should match with some function definitions provided in
-the patch file. The following command will attempt to apply all such changes
-from the patch into the ``openvswitch/datapath/linux/compat`` directory; Like
-the previous ``git am`` command above, it may succeed or fail. If it succeeds,
-review the patch and proceed to the next patch using ``git am --continue``.
-
-::
-
-    $ git am -p3 --reject --directory='datapath/linux/compat/' <patch>
-
-For each conflicting hunk, attempt to resolve the change so that the function
-reflects what the function looks like in the upstream Linux tree. After
-resolving these changes, compile the changes, add the modified files to the
-index using ``git add``, review the patch, and proceed to the next patch using
-``git am --continue``.
-
 Submission
 ~~~~~~~~~~
 
-Once the patches are all assembled and working on the Open vSwitch tree, they
+Once the patches are all assembled and working on the OVN tree, they
 need to be formatted again using ``git format-patch``. The common format for
 commit messages for Linux backport patches is as follows:
 
diff --git a/Documentation/internals/contributing/coding-style-windows.rst b/Documentation/internals/contributing/coding-style-windows.rst
deleted file mode 100644
index f7bc51ed4b74..000000000000
--- a/Documentation/internals/contributing/coding-style-windows.rst
+++ /dev/null
@@ -1,183 +0,0 @@ 
-..
-      Licensed under the Apache License, Version 2.0 (the "License"); you may
-      not use this file except in compliance with the License. You may obtain
-      a copy of the License at
-
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
-      WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
-      License for the specific language governing permissions and limitations
-      under the License.
-
-      Convention for heading levels in OVN documentation:
-
-      =======  Heading 0 (reserved for the title in a document)
-      -------  Heading 1
-      ~~~~~~~  Heading 2
-      +++++++  Heading 3
-      '''''''  Heading 4
-
-      Avoid deeper levels because they do not render well.
-
-==========================================
-Open vSwitch Windows Datapath Coding Style
-==========================================
-
-The :doc:`coding style <coding-style>` guide gives the flexibility for each
-platform to use its own coding style for the kernel datapath.  This file
-describes the specific coding style used in most of the C files in the Windows
-kernel datapath of the Open vSwitch distribution.
-
-Most of the coding conventions applicable for the Open vSwitch distribution are
-applicable to the Windows kernel datapath as well.  There are some exceptions
-and new guidelines owing to the commonly followed practices in Windows
-kernel/driver code.  They are noted as follows:
-
-Basics
-------
-
-- Limit lines to 79 characters.
-
-  Many times, this is not possible due to long names of functions and it is
-  fine to go beyond the characters limit.  One common example is when calling
-  into NDIS functions.
-
-Types
------
-
-Use data types defined by Windows for most of the code.  This is a common
-practice in Windows driver code, and it makes integrating with the data
-structures and functions defined by Windows easier.  Example: ``DWORD`` and
-``BOOLEAN``.
-
-Use caution in portions of the code that interface with the OVS userspace.  OVS
-userspace does not use Windows specific data types, and when copying data back
-and forth between kernel and userspace, care should be exercised.
-
-Naming
-------
-
-It is common practice to use camel casing for naming variables, functions and
-files in Windows.  For types, especially structures, unions and enums, using
-all upper case letters with words separated by '_' is common. These practices
-can be used for OVS Windows datapath.  However, use the following guidelines:
-
-- Use lower case to begin the name of a variable.
-
-- Do not use '_' to begin the name of the variable. '_' is to be used to begin
-  the parameters of a pre-processor macro.
-
-- Use upper case to begin the name of a function, enum, file name etc.
-
-- Static functions whose scope is limited to the file they are defined in can
-  be prefixed with '_'. This is not mandatory though.
-
-- For types, use all upper case for all letters with words separated by '_'. If
-  camel casing is preferred, use  upper case for the first letter.
-
-- It is a common practice to define a pointer type by prefixing the letter 'P'
-  to a data type.  The same practice can be followed here as well.
-
-For example::
-
-    static __inline BOOLEAN
-    OvsDetectTunnelRxPkt(POVS_FORWARDING_CONTEXT ovsFwdCtx,
-                         POVS_FLOW_KEY flowKey)
-    {
-        POVS_VPORT_ENTRY tunnelVport = NULL;
-
-        if (!flowKey->ipKey.nwFrag &&
-            flowKey->ipKey.nwProto == IPPROTO_UDP &&
-            flowKey->ipKey.l4.tpDst == VXLAN_UDP_PORT_NBO) {
-            tunnelVport = OvsGetTunnelVport(OVSWIN_VPORT_TYPE_VXLAN);
-            ovsActionStats.rxVxlan++;
-        } else {
-            return FALSE;
-        }
-
-        if (tunnelVport) {
-            ASSERT(ovsFwdCtx->tunnelRxNic == NULL);
-            ovsFwdCtx->tunnelRxNic = tunnelVport;
-            return TRUE;
-        }
-
-        return FALSE;
-    }
-
-For declaring variables of pointer type, use of the pointer data type prefixed
-with 'P' is preferred over using '*'. This is not mandatory though, and is only
-prescribed since it is a common practice in Windows.
-
-Example, #1 is preferred over #2 though #2 is also equally correct:
-
-1. ``PNET_BUFFER_LIST curNbl;``
-2. ``NET_BUFFER_LIST *curNbl;``
-
-Comments
---------
-
-Comments should be written as full sentences that start with a capital letter
-and end with a period.  Putting two spaces between sentences is not necessary.
-
-``//`` can be used for comments as long as the comment is a single line
-comment.  For block comments, use ``/* */`` comments
-
-Functions
----------
-
-Put the return type, function name, and the braces that surround the function's
-code on separate lines, all starting in column 0.
-
-Before each function definition, write a comment that describes the function's
-purpose, including each parameter, the return value, and side effects.
-References to argument names should be given in single-quotes, e.g. 'arg'.  The
-comment should not include the function name, nor need it follow any formal
-structure.  The comment does not need to describe how a function does its work,
-unless this information is needed to use the function correctly (this is often
-better done with comments *inside* the function).
-
-Mention any side effects that the function has that are not obvious based on
-the name of the function or based on the workflow it is called from.
-
-In the interest of keeping comments describing functions similar in structure,
-use the following template.
-
-::
-
-    /*
-     *----------------------------------------------------------------------------
-     * Any description of the function, arguments, return types, assumptions and
-     * side effects.
-     *----------------------------------------------------------------------------
-     */
-
-Source Files
-------------
-
-Each source file should state its license in a comment at the very top,
-followed by a comment explaining the purpose of the code that is in that file.
-The comment should explain how the code in the file relates to code in other
-files.  The goal is to allow a programmer to quickly figure out where a given
-module fits into the larger system.
-
-The first non-comment line in a .c source file should be::
-
-    #include <precomp.h>
-
-``#include`` directives should appear in the following order:
-
-1. ``#include <precomp.h>``
-
-2. The module's own headers, if any.  Including this before any other header
-   (besides ``<precomp.h>``) ensures that the module's header file is
-   self-contained (see *Header Files*) below.
-
-3. Standard C library headers and other system headers, preferably in
-   alphabetical order.  (Occasionally one encounters a set of system headers
-   that must be included in a particular order, in which case that order must
-   take precedence.)
-
-4. Open vSwitch headers, in alphabetical order.  Use ``""``, not ``<>``, to
-   specify Open vSwitch header names.
diff --git a/Documentation/internals/contributing/coding-style.rst b/Documentation/internals/contributing/coding-style.rst
index 9fc3b0bd13a6..7e93f0881bf8 100644
--- a/Documentation/internals/contributing/coding-style.rst
+++ b/Documentation/internals/contributing/coding-style.rst
@@ -21,14 +21,12 @@ 
 
       Avoid deeper levels because they do not render well.
 
-=========================
-Open vSwitch Coding Style
-=========================
+================
+OVN Coding Style
+================
 
-This file describes the coding style used in most C files in the Open vSwitch
-distribution. However, Linux kernel code datapath directory follows the Linux
-kernel's established coding conventions. For the Windows kernel datapath code,
-use the coding style described in :doc:`coding-style-windows`.
+This file describes the coding style used in C files in the OVN
+distribution.
 
 The following GNU indent options approximate this style.
 
@@ -408,8 +406,8 @@  The first non-comment line in a ``.c`` source file should be:
    that must be included in a particular order, in which case that order must
    take precedence.)
 
-4. Open vSwitch headers, in alphabetical order. Use ``""``, not ``<>``, to
-   specify Open vSwitch header names.
+4. OVN headers, in alphabetical order. Use ``""``, not ``<>``, to
+   specify OVN header names.
 
 .. _header files:
 
diff --git a/Documentation/internals/contributing/documentation-style.rst b/Documentation/internals/contributing/documentation-style.rst
index 7e21283caaa0..e86fcf19c660 100644
--- a/Documentation/internals/contributing/documentation-style.rst
+++ b/Documentation/internals/contributing/documentation-style.rst
@@ -23,21 +23,15 @@ 
 
       Avoid deeper levels because they do not render well.
 
-================================
-Open vSwitch Documentation Style
-================================
+=======================
+OVN Documentation Style
+=======================
 
 This file describes the documentation style used in all documentation found in
-Open vSwitch. Documentation includes any documents found in ``Documentation``
+OVN. Documentation includes any documents found in ``Documentation``
 along with any ``README``, ``MAINTAINERS``, or generally ``rst`` suffixed
 documents found in the project tree.
 
-.. note::
-
-   This guide only applies to documentation for Open vSwitch v2.7. or greater.
-   Previous versions of Open vSwitch used a combination of Markdown and raw
-   plain text, and guidelines for these are not detailed here.
-
 reStructuredText vs. Sphinx
 ---------------------------
 
@@ -336,7 +330,7 @@  In addition to the above, man pages have some specific requirements:
 
      Option argument names should be enclosed in angle brackets, as above.
 
-- Any references to the application or any other Open vSwitch application must
+- Any references to the application or any other OVN application must
   be marked up using the `program` role.
 
   This allows for easy linking in the HTML output and correct formatting in the
diff --git a/Documentation/internals/contributing/index.rst b/Documentation/internals/contributing/index.rst
index 61f2b042c89b..77b52964b716 100644
--- a/Documentation/internals/contributing/index.rst
+++ b/Documentation/internals/contributing/index.rst
@@ -21,11 +21,11 @@ 
 
       Avoid deeper levels because they do not render well.
 
-============================
-Contributing to Open vSwitch
-============================
+===================
+Contributing to OVN
+===================
 
-The below guides provide information on contributing to Open vSwitch itself.
+The below guides provide information on contributing to OVN itself.
 
 .. toctree::
    :maxdepth: 2
@@ -33,6 +33,5 @@  The below guides provide information on contributing to Open vSwitch itself.
    submitting-patches
    backporting-patches
    coding-style
-   coding-style-windows
    documentation-style
    libopenvswitch-abi
diff --git a/Documentation/internals/contributing/submitting-patches.rst b/Documentation/internals/contributing/submitting-patches.rst
index ecee7f418bbe..5889e3c44aad 100644
--- a/Documentation/internals/contributing/submitting-patches.rst
+++ b/Documentation/internals/contributing/submitting-patches.rst
@@ -25,7 +25,7 @@ 
 Submitting Patches
 ==================
 
-Send changes to Open vSwitch as patches to dev@openvswitch.org.  One patch per
+Send changes to OVN as patches to dev@openvswitch.org.  One patch per
 email.  More details are included below.
 
 If you are using Git, then `git format-patch` takes care of most of the
@@ -89,7 +89,7 @@  Where:
   sending only one patch.
 
 ``<area>``:
-  indicates the area of the Open vSwitch to which the change applies (often the
+  indicates the area of OVN to which the change applies (often the
   name of a source file or a directory).  You may omit it if the change crosses
   multiple distinct pieces of code.
 
@@ -129,7 +129,7 @@  The description should include:
 There is no need to describe what the patch actually changed, if the reader can
 see it for himself.
 
-If the patch refers to a commit already in the Open vSwitch repository, please
+If the patch refers to a commit already in the OVN repository, please
 include both the commit number and the subject of the patch, e.g. 'commit
 632d136c (vswitch: Remove restriction on datapath names.)'.
 
@@ -265,9 +265,9 @@  Examples of common tags follow.
 
 ``Submitted-at: <URL>``
 
-  If a patch was submitted somewhere other than the Open vSwitch
-  development mailing list, such as a GitHub pull request, this header can
-  be used to reference the source.
+  If a patch was submitted somewhere other than the OVN development
+  mailing list, such as a GitHub pull request, this header can be used
+  to reference the source.
 
   ::
 
@@ -300,7 +300,7 @@  Examples of common tags follow.
 
   If you would like to record which commit introduced a bug being fixed,
   you may do that with a “Fixes” header.  This assists in determining
-  which OVS releases have the bug, so the patch can be applied to all
+  which OVN releases have the bug, so the patch can be applied to all
   affected versions.  The easiest way to generate the header in the
   proper format is with this git command.  This command also CCs the
   author of the commit being fixed, which makes sense unless the
@@ -327,7 +327,7 @@  Developer's Certificate of Origin
 
 To help track the author of a patch as well as the submission chain, and be
 clear that the developer has authority to submit a patch for inclusion in
-Open vSwitch please sign off your work.  The sign off certifies the following:
+OVN please sign off your work.  The sign off certifies the following:
 
 ::
 
@@ -362,19 +362,19 @@  See also http://developercertificate.org/.
 Feature Deprecation Guidelines
 ------------------------------
 
-Open vSwitch is intended to be user friendly.  This means that under normal
-circumstances we don't abruptly remove features from OVS that some users might
+OVN is intended to be user friendly.  This means that under normal
+circumstances we don't abruptly remove features from OVN that some users might
 still be using.  Otherwise, if we would, then we would possibly break our user
 setup when they upgrade and would receive bug reports.
 
-Typical process to deprecate a feature in Open vSwitch is to:
+Typical process to deprecate a feature in OVN is to:
 
 (a) Mention deprecation of a feature in the NEWS file.  Also, mention expected
-    release or absolute time when this feature would be removed from OVS
+    release or absolute time when this feature would be removed from OVN
     altogether.  Don't use relative time (e.g. "in 6 months") because that is
     not clearly interpretable.
 
-(b) If Open vSwitch is configured to use deprecated feature it should print
+(b) If OVN is configured to use deprecated feature it should print
     a warning message to the log files clearly indicating that feature is
     deprecated and that use of it should be avoided.
 
@@ -384,9 +384,9 @@  Typical process to deprecate a feature in Open vSwitch is to:
 Also, if there is alternative feature to the one that is about to be marked as
 deprecated, then mention it in (a), (b) and (c) as well.
 
-Remember to follow-up and actually remove the feature from OVS codebase once
+Remember to follow-up and actually remove the feature from OVN codebase once
 deprecation grace period has expired and users had opportunity to use at least
-one OVS release that would have informed them about feature deprecation!
+one OVN release that would have informed them about feature deprecation!
 
 Comments
 --------
@@ -416,14 +416,11 @@  cannot convince your email client not to mangle patches, then sending the patch
 as an attachment is a second choice.
 
 Follow the style used in the code that you are modifying. :doc:`coding-style`
-file describes the coding style used in most of Open vSwitch. Use Linux kernel
-coding style for Linux kernel code.
-
-If your code is non-datapath code, you may use the ``utilities/checkpatch.py``
-utility as a quick check for certain commonly occurring mistakes (improper
-leading/trailing whitespace, missing signoffs, some improper formatted patch
-files).  For Linux datapath code, it is a good idea to use the Linux script
-``checkpatch.pl``.
+file describes the coding style used in most of OVN.
+
+You may use the ``utilities/checkpatch.py`` utility as a quick check
+for certain commonly occurring mistakes (improper leading/trailing
+whitespace, missing signoffs, some improper formatted patch files).
 
 Example
 -------
diff --git a/Documentation/internals/documentation.rst b/Documentation/internals/documentation.rst
index 424f244b40cf..f7077acb949e 100644
--- a/Documentation/internals/documentation.rst
+++ b/Documentation/internals/documentation.rst
@@ -23,18 +23,18 @@ 
 
       Avoid deeper levels because they do not render well.
 
-======================================
-How Open vSwitch's Documentation Works
-======================================
+=============================
+How OVN's Documentation Works
+=============================
 
 This document provides a brief overview on how the documentation build system
-within Open vSwitch works. This is intended to maximize the "bus factor" and
+within OVN works. This is intended to maximize the "bus factor" and
 share best practices with other projects.
 
 reStructuredText and Sphinx
 ---------------------------
 
-Nearly all of Open vSwitch's documentation is written in `reStructuredText`__,
+Nearly all of OVN's documentation is written in `reStructuredText`__,
 with man pages being the sole exception. Of this documentation, most of it is
 fed into `Sphinx`__, which provides not only the ability to convert rST to a
 variety of other output formats but also allows for things like
@@ -45,11 +45,11 @@  ovs-sphinx-theme
 ----------------
 
 The documentation uses its own theme, `ovs-sphinx-theme`, which can be found on
-GitHub__ and is published on pypi__. This is packaged separately from Open
-vSwitch itself to ensure all documentation gets the latest version of the theme
-(assuming there are no major version bumps in that package). If building
-locally and the package is installed, it will be used. If the package is not
-installed, Sphinx will fallback to the default theme.
+GitHub__ and is published on pypi__. This is shared by Open vSwitch and OVN.
+It is packaged separately to ensure all documentation gets the latest version
+of the theme (assuming there are no major version bumps in that package). If
+building locally and the package is installed, it will be used. If the package
+is not installed, Sphinx will fallback to the default theme.
 
 The package is currently maintained by Stephen Finucane and Russell Bryant.
 
diff --git a/Documentation/internals/index.rst b/Documentation/internals/index.rst
index cf54d74b3ea1..d70a39d55b92 100644
--- a/Documentation/internals/index.rst
+++ b/Documentation/internals/index.rst
@@ -23,11 +23,11 @@ 
 
       Avoid deeper levels because they do not render well.
 
-======================
-Open vSwitch Internals
-======================
+=============
+OVN Internals
+=============
 
-Information for people who want to know more about the Open vSwitch project
+Information for people who want to know more about the OVN project
 itself and how they might involved.
 
 .. toctree::
diff --git a/Documentation/internals/mailing-lists.rst b/Documentation/internals/mailing-lists.rst
index 88f875357148..83fe54b46a3c 100644
--- a/Documentation/internals/mailing-lists.rst
+++ b/Documentation/internals/mailing-lists.rst
@@ -32,8 +32,9 @@  Mailing Lists
 ovs-announce
 ------------
 
-The `ovs-announce`__ mailing list is used to announce new versions of Open
-vSwitch and is extremely low-volume. `(subscribe)`__ `(archives)`__
+The `ovs-announce`__ mailing list is used to announce new versions of
+Open vSwitch and OVN and is extremely low-volume. `(subscribe)`__
+`(archives)`__
 
 __ ovs-announce@openvswitch.org
 __ https://mail.openvswitch.org/mailman/listinfo/ovs-announce/
@@ -43,7 +44,7 @@  ovs-discuss
 -----------
 
 The `ovs-discuss`__ mailing list is used to discuss plans and design decisions
-for Open vSwitch. It is also an appropriate place for user questions.
+for Open vSwitch and OVN. It is also an appropriate place for user questions.
 `(subscribe)`__ `(archives)`__
 
 __ ovs-discuss@openvswitch.org
@@ -60,26 +61,6 @@  __ ovs-dev@openvswitch.org
 __ https://mail.openvswitch.org/mailman/listinfo/ovs-dev/
 __ https://mail.openvswitch.org/pipermail/ovs-dev/
 
-ovs-git
--------
-
-The `ovs-git`__ mailing list hooks into Open vSwitch's version control system
-to receive commits. `(subscribe)`__ `(archives)`__
-
-__ ovs-git@openvswitch.org
-__ https://mail.openvswitch.org/mailman/listinfo/ovs-git/
-__ https://mail.openvswitch.org/pipermail/ovs-git/
-
-ovs-build
----------
-
-The `ovs-build`__ mailing list hooks into Open vSwitch's continuous integration
-system to receive build reports. `(subscribe)`__ `(archives)`__
-
-__ ovs-build@openvswitch.org
-__ https://mail.openvswitch.org/mailman/listinfo/ovs-build/
-__ https://mail.openvswitch.org/pipermail/ovs-build/
-
 bugs
 -----
 
@@ -93,4 +74,4 @@  security
 The `security`__ mailing list is for submitting security vulnerabilities to the
 security team.
 
-__ security@ovs.org
+__ security@openvswitch.org
diff --git a/Documentation/internals/patchwork.rst b/Documentation/internals/patchwork.rst
index 379ad7d24b66..f1f827476c10 100644
--- a/Documentation/internals/patchwork.rst
+++ b/Documentation/internals/patchwork.rst
@@ -27,12 +27,12 @@ 
 Patchwork
 =========
 
-Open vSwitch uses `Patchwork`__ to track the status of patches sent to the
-:doc:`ovs-dev mailing list <mailing-lists>`. The Open vSwitch Patchwork
+Open vSwitch and OVN use `Patchwork`__ to track the status of patches
+sent to the :doc:`ovs-dev mailing list <mailing-lists>`. Our Patchwork
 instance can be found on `ozlabs.org`__.
 
-Patchwork provides a number of useful features for developers working on Open
-vSwitch:
+Patchwork provides a number of useful features for developers working on
+Open vSwitch and OVN:
 
 - Tracking the lifecycle of patches (accepted, rejected, under-review, ...)
 - Assigning reviewers (delegates) to patches
@@ -60,7 +60,7 @@  from your `Patchwork User Profile`__ page. If you do not already have a
 Patchwork user account, you should create one now.
 
 Once your token is obtained, configure *git-pw* as below. Note that this must
-be run from within the Open vSwitch Git repository::
+be run from within the OVN Git repository::
 
     $ git config pw.server https://patchwork.ozlabs.org/
     $ git config pw.project openvswitch
diff --git a/Documentation/internals/release-process.rst b/Documentation/internals/release-process.rst
index 2f6836a5f554..3396177b8059 100644
--- a/Documentation/internals/release-process.rst
+++ b/Documentation/internals/release-process.rst
@@ -21,20 +21,20 @@ 
 
       Avoid deeper levels because they do not render well.
 
-============================
-Open vSwitch Release Process
-============================
+===================
+OVN Release Process
+===================
 
-This document describes the process ordinarily used for Open vSwitch
+This document describes the process ordinarily used for OVN
 development and release.  Exceptions are sometimes necessary, so all of the
 statements here should be taken as subject to change through rough consensus of
-Open vSwitch contributors, obtained through public discussion on, e.g., ovs-dev
+OVN contributors, obtained through public discussion on, e.g., ovs-dev
 or the #openvswitch IRC channel.
 
 Release Strategy
 ----------------
 
-Open vSwitch feature development takes place on the "master" branch.
+OVN feature development takes place on the "master" branch.
 Ordinarily, new features are rebased against master and applied directly.  For
 features that take significant development, sometimes it is more appropriate to
 merge a separate branch into master; please discuss this on ovs-dev in advance.
@@ -50,7 +50,7 @@  Scheduling`_ for the timing of each stage:
    Please propose and discuss exceptions on ovs-dev.
  
 2. Fork a release branch from master, named for the expected release number,
-   e.g. "branch-2.3" for the branch that will yield Open vSwitch 2.3.x.
+   e.g. "branch-2.3" for the branch that will yield OVN 2.3.x.
 
    Release branches are intended for testing and stabilization.  At this stage
    and in later stages, they should receive only bug fixes, not new features.
@@ -67,7 +67,7 @@  Scheduling`_ for the timing of each stage:
 3. When committers come to rough consensus that the release is ready, they
    release the .0 release on its branch, e.g. 2.3.0 for branch-2.3.  To make
    the actual release, a committer pushes a signed tag named, e.g. v2.3.0, to
-   the Open vSwitch repository, makes a release tarball available on
+   the OVN repository, makes a release tarball available on
    openvswitch.org, and posts a release announcement to ovs-announce.
 
 4. As bug fixes accumulate, or after important bugs or vulnerabilities are
@@ -77,11 +77,11 @@  Scheduling`_ for the timing of each stage:
 
 At most two release branches are formally maintained at any given time: the
 latest release and the latest release designed as LTS.  An LTS release is one
-that the OVS project has designated as being maintained for a longer period of
+that the OVN project has designated as being maintained for a longer period of
 time.  Currently, an LTS release is maintained until the next LTS is chosen.
 There is not currently a strict guideline on how often a new LTS release is
 chosen, but so far it has been about every 2 years.  That could change based on
-the current state of OVS development.  For example, we do not want to designate
+the current state of OVN development.  For example, we do not want to designate
 a new release as LTS that includes disruptive internal changes, as that may
 make it harder to support for a longer period of time.  Discussion about
 choosing the next LTS release occurs on the OVS development mailing list.
@@ -90,7 +90,7 @@  Release Numbering
 -----------------
 
 The version number on master should normally end in .90.  This indicates that
-the Open vSwitch version is "almost" the next version to branch.
+the OVN version is "almost" the next version to branch.
 
 Forking master into branch-x.y requires two commits to master.  The first is
 titled "Prepare for x.y.0" and increments the version number to x.y.  This is
@@ -107,7 +107,7 @@  and adds a blank item to NEWS with an unspecified date.
 Release Scheduling
 ------------------
 
-Open vSwitch makes releases at the following six-month cadence.  All dates are
+OVN makes releases at the following six-month cadence.  All dates are
 approximate:
 
 +---------------+----------------+--------------------------------------+
@@ -125,5 +125,5 @@  approximate:
 Contact
 -------
 
-Use dev@openvswitch.org to discuss the Open vSwitch development and release
-process.
+Use dev@openvswitch.org to discuss the Open vSwitch and OVN
+development and release processes.
diff --git a/Documentation/internals/security.rst b/Documentation/internals/security.rst
index c6d936e2b2b8..c1fa2d8387c7 100644
--- a/Documentation/internals/security.rst
+++ b/Documentation/internals/security.rst
@@ -21,21 +21,20 @@ 
 
       Avoid deeper levels because they do not render well.
 
-===============================
-Open vSwitch's Security Process
-===============================
+======================
+OVN's Security Process
+======================
 
 This is a proposed security vulnerability reporting and handling process for
-Open vSwitch. It is based on the OpenStack vulnerability management process
+OVN. It is based on the OpenStack vulnerability management process
 described at https://wiki.openstack.org/wiki/Vulnerability\_Management.
 
-The OVS security team coordinates vulnerability management using the
+The OVN security team coordinates vulnerability management using the
 ovs-security mailing list. Membership in the security team and subscription to
 its mailing list consists of a small number of trustworthy people, as
-determined by rough consensus of the Open vSwitch committers on the
-ovs-committers mailing list. The Open vSwitch security team should include Open
-vSwitch committers, to ensure prompt and accurate vulnerability assessments and
-patch review.
+determined by rough consensus of the OVN committers.  The OVN security team
+should include OVN committers, to ensure prompt and accurate vulnerability
+assessments and patch review.
 
 We encourage everyone involved in the security process to GPG-sign their
 emails. We additionally encourage GPG-encrypting one-on-one conversations as
@@ -68,7 +67,7 @@  this process:
   (Integrity).
 
 * A bug (memory corruption, overflow, ...) that allows one to modify the
-  behaviour of OVS through external configuration interfaces such as OVSDB
+  behaviour of OVN through external configuration interfaces such as OVSDB
   (Integrity).
 
 * Privileged information is exposed to unprivileged users (Confidentiality).
@@ -79,7 +78,7 @@  response will be to report the bug through the usual channels.
 Step 1: Reception
 -----------------
 
-To report an Open vSwitch vulnerability, send an email to the ovs-security
+To report an OVN vulnerability, send an email to the ovs-security
 mailing list (see contact_ at the end of this document). A security team
 member should reply to the reporter acknowledging that the report has been
 received.
@@ -89,20 +88,13 @@  Consider reporting the information mentioned in :doc:`bugs`, where relevant.
 Reporters may ask for a GPG key while initiating contact with the security team
 to deliver more sensitive reports.
 
-The Linux kernel has `its own vulnerability management process
-<https://static.lwn.net/kerneldoc/admin-guide/security-bugs.html>`__.  Handling
-of vulnerabilities that affect both the Open vSwitch tree and the upstream
-Linux kernel should be reported through both processes.  Send your report as a
-single email to both the kernel and OVS security teams to allow those teams to
-most easily coordinate among themselves.
-
 Step 2: Assessment
 ------------------
 
 The security team should discuss the vulnerability. The reporter should be
 included in the discussion (via "CC") to an appropriate degree.
 
-The assessment should determine which Open vSwitch versions are affected (e.g.
+The assessment should determine which OVN versions are affected (e.g.
 every version, only the latest release, only unreleased versions), the
 privilege required to take advantage of the vulnerability (e.g. any network
 user, any local L2 network user, any local system user, connected OpenFlow
@@ -129,7 +121,7 @@  sections for the document include:
 ::
 
     * Title: The CVE identifier, a short description of the
-      vulnerability.  The title should mention Open vSwitch.
+      vulnerability.  The title should mention OVN.
 
       In email, the title becomes the subject.  Pre-release advisories
       are often passed around in encrypted email, which have plaintext
@@ -137,14 +129,14 @@  sections for the document include:
 
     * Description: A few paragraphs describing the general
       characteristics of the vulnerability, including the versions of
-      Open vSwitch that are vulnerable, the kind of attack that
+      OVN that are vulnerable, the kind of attack that
       exposes the vulnerability, and potential consequences of the
       attack.
 
       The description should re-state the CVE identifier, in case the
       subject is lost when an advisory is sent over email.
 
-    * Mitigation: How an Open vSwitch administrator can minimize the
+    * Mitigation: How an OVN administrator can minimize the
       potential for exploitation of the vulnerability, before applying
       a fix.  If no mitigation is possible or recommended, explain
       why, to reduce the chance that at-risk users believe they are
@@ -162,8 +154,7 @@  sections for the document include:
     * Acknowledgments: Thank the reporters.
 
     * Vulnerability Check: A step-by-step procedure by which a user
-      can determine whether an installed copy of Open vSwitch is
-      vulnerable.
+      can determine whether an installed copy of OVN is vulnerable.
 
       The procedure should clearly describe how to interpret the
       results, including expected results in vulnerable and
@@ -172,7 +163,7 @@  sections for the document include:
 
       The procedure should assume as little understanding of Open
       vSwitch as possible, to make it more likely that a competent
-      administrator who does not specialize in Open vSwitch can
+      administrator who does not specialize in OVN can
       perform it successfully.
 
       The procedure should have minimal dependencies on tools that are
@@ -190,11 +181,10 @@  sections for the document include:
       it has been tested.
 
       This section should state the risks of the procedure.  For
-      example, if it can crash Open vSwitch or disrupt packet
-      forwarding, say so.
+      example, if it can crash OVN or disrupt packet forwarding, say so.
 
       It is more useful to explain how to check an installed and
-      running Open vSwitch than one built locally from source, but if
+      running OVN than one built locally from source, but if
       it is easy to use the procedure from a sandbox environment, it
       can be helpful to explain how to do so.
 
@@ -204,12 +194,11 @@  sections for the document include:
       output by "git format-patch".
 
       The patch subjects should include the version for which they are
-      suited, e.g. "[PATCH branch-2.3]" for a patch against Open
-      vSwitch 2.3.x.  If there are multiple patches for multiple
-      versions of Open vSwitch, put them in separate sections with
-      clear titles.
+      suited, e.g. "[PATCH branch-2.3]" for a patch against OVN 2.3.x.
+      If there are multiple patches for multiple versions of OVN, put
+      them in separate sections with clear titles.
 
-      Multiple patches for a single version of Open vSwitch, that must
+      Multiple patches for a single version of OVN, that must
       be stacked on top of each other to fix a single vulnerability,
       are undesirable because users are less likely to apply all of
       them correctly and in the correct order.
@@ -241,14 +230,14 @@  embargo date and time set from the time sent. Downstream stakeholders are
 expected not to deploy or disclose patches until the embargo is passed.
 
 A disclosure date is negotiated by the security team working with the bug
-submitter as well as vendors. However, the Open vSwitch security team holds the
+submitter as well as vendors. However, the OVN security team holds the
 final say when setting a disclosure date. The timeframe for disclosure is from
 immediate (esp. if it's already publicly known) to a few weeks. As a basic
 default policy, we expect report date to disclosure date to be 10 to 15
 business days.
 
 Operating system vendors are obvious downstream stakeholders. It may not be
-necessary to be too choosy about who to include: any major Open vSwitch user
+necessary to be too choosy about who to include: any major OVN user
 who is interested and can be considered trustworthy enough could be included.
 To become a downstream stakeholder, email the ovs-security mailing list.
 
@@ -260,8 +249,8 @@  Step 5: Public Disclosure
 When the embargo expires, push the (reviewed) patches to appropriate branches,
 post the patches to the ovs-dev mailing list (noting that they have already
 been reviewed and applied), post the security advisory to appropriate mailing
-lists (ovs-announce, ovs-discuss), and post the security advisory on the Open
-vSwitch webpage.
+lists (ovs-announce, ovs-discuss), and post the security advisory on the OVN
+webpage.
 
 When the patch is applied to LTS (long-term support) branches, a new version
 should be released.
diff --git a/manpages.mk b/manpages.mk
index 6349e2845309..44e544681424 100644
--- a/manpages.mk
+++ b/manpages.mk
@@ -1,103 +1,5 @@ 
 # Generated automatically -- do not modify!    -*- buffer-read-only: t -*-
 
-ovs/ovsdb/ovsdb-client.1: \
-	ovs/ovsdb/ovsdb-client.1.in \
-	lib/common-syn.man \
-	lib/common.man \
-	lib/daemon-syn.man \
-	lib/daemon.man \
-	lib/ovs.tmac \
-	lib/ssl-bootstrap-syn.man \
-	lib/ssl-bootstrap.man \
-	lib/ssl-connect-syn.man \
-	lib/ssl-connect.man \
-	lib/ssl-syn.man \
-	lib/ssl.man \
-	lib/table.man \
-	lib/vlog-syn.man \
-	lib/vlog.man \
-	ovsdb/ovsdb-schemas.man
-ovs/ovsdb/ovsdb-client.1.in:
-lib/common-syn.man:
-lib/common.man:
-lib/daemon-syn.man:
-lib/daemon.man:
-lib/ovs.tmac:
-lib/ssl-bootstrap-syn.man:
-lib/ssl-bootstrap.man:
-lib/ssl-connect-syn.man:
-lib/ssl-connect.man:
-lib/ssl-syn.man:
-lib/ssl.man:
-lib/table.man:
-lib/vlog-syn.man:
-lib/vlog.man:
-ovsdb/ovsdb-schemas.man:
-
-ovs/ovsdb/ovsdb-server.1: \
-	ovs/ovsdb/ovsdb-server.1.in \
-	lib/common-syn.man \
-	lib/common.man \
-	lib/coverage-unixctl.man \
-	lib/daemon-syn.man \
-	lib/daemon.man \
-	lib/memory-unixctl.man \
-	lib/ovs.tmac \
-	lib/service-syn.man \
-	lib/service.man \
-	lib/ssl-bootstrap-syn.man \
-	lib/ssl-bootstrap.man \
-	lib/ssl-connect-syn.man \
-	lib/ssl-connect.man \
-	lib/ssl-peer-ca-cert-syn.man \
-	lib/ssl-peer-ca-cert.man \
-	lib/ssl-syn.man \
-	lib/ssl.man \
-	lib/unixctl-syn.man \
-	lib/unixctl.man \
-	lib/vlog-syn.man \
-	lib/vlog-unixctl.man \
-	lib/vlog.man
-ovs/ovsdb/ovsdb-server.1.in:
-lib/common-syn.man:
-lib/common.man:
-lib/coverage-unixctl.man:
-lib/daemon-syn.man:
-lib/daemon.man:
-lib/memory-unixctl.man:
-lib/ovs.tmac:
-lib/service-syn.man:
-lib/service.man:
-lib/ssl-bootstrap-syn.man:
-lib/ssl-bootstrap.man:
-lib/ssl-connect-syn.man:
-lib/ssl-connect.man:
-lib/ssl-peer-ca-cert-syn.man:
-lib/ssl-peer-ca-cert.man:
-lib/ssl-syn.man:
-lib/ssl.man:
-lib/unixctl-syn.man:
-lib/unixctl.man:
-lib/vlog-syn.man:
-lib/vlog-unixctl.man:
-lib/vlog.man:
-
-ovs/ovsdb/ovsdb-tool.1: \
-	ovs/ovsdb/ovsdb-tool.1.in \
-	lib/common-syn.man \
-	lib/common.man \
-	lib/ovs.tmac \
-	lib/vlog-syn.man \
-	lib/vlog.man \
-	ovsdb/ovsdb-schemas.man
-ovs/ovsdb/ovsdb-tool.1.in:
-lib/common-syn.man:
-lib/common.man:
-lib/ovs.tmac:
-lib/vlog-syn.man:
-lib/vlog.man:
-ovsdb/ovsdb-schemas.man:
-
 utilities/ovn-detrace.1: \
 	utilities/ovn-detrace.1.in \
 	lib/common-syn.man \