docs: Fix typos and formatting

Correct spelling mistakes and formatting issues.

Fixes: #1792.

Signed-off-by: James O. D. Hunt <[email protected]>

pkg/katatestutils/README.md

@@ -11,7 +11,7 @@
     * [Full details](#full-details)
 
 This package provides a small set of test utilities. See the
-[godoc](https://godoc.org/github.com/kata-containers/runtime/pkg/katatestutils)
+[GoDoc](https://godoc.org/github.com/kata-containers/runtime/pkg/katatestutils)
 for full details.
 
 ## Test Constraints
@@ -175,4 +175,4 @@ func TestOldKernelVersion(t *testing.T) {
 ### Full details
 
 The public API is shown in [`constraints_api.go`](constraints_api.go) or
-the [godoc](https://godoc.org/github.com/kata-containers/runtime/pkg/katatestutils).
+the [GoDoc](https://godoc.org/github.com/kata-containers/runtime/pkg/katatestutils).

virtcontainers/README.md

@@ -31,7 +31,7 @@ runtimes.
 
 # Background
 
-The few existing VM-based container runtimes (Clear Containers, runv, rkt's
+The few existing VM-based container runtimes (Clear Containers, runV, rkt's
 KVM stage 1) all share the same hardware virtualization semantics but use different
 code bases to implement them. `virtcontainers`'s goal is to factorize this code into
 a common Go library.
@@ -214,8 +214,8 @@ __Runtime network setup with CNM__
 __Drawbacks of CNM__
 
 There are three drawbacks about using CNM instead of CNI:
-* The way we call into it is not very explicit: Have to re-exec dockerd binary so that it can accept parameters and execute the prestart hook related to network setup.
-* Implicit way to designate the network namespace: Instead of explicitly giving the netns to dockerd, we give it the PID of our runtime so that it can find the netns from this PID. This means we have to make sure being in the right netns while calling the hook, otherwise the VETH pair will be created with the wrong netns.
+* The way we call into it is not very explicit: Have to re-exec `dockerd` binary so that it can accept parameters and execute the prestart hook related to network setup.
+* Implicit way to designate the network namespace: Instead of explicitly giving the netns to `dockerd`, we give it the PID of our runtime so that it can find the netns from this PID. This means we have to make sure being in the right netns while calling the hook, otherwise the VETH pair will be created with the wrong netns.
 * No results are back from the hook: We have to scan the network interfaces to discover which one has been created inside the netns. This introduces more latency in the code because it forces us to scan the network in the `CreateSandbox` path, which is critical for starting the VM as quick as possible.
 
 # Storage
@@ -236,7 +236,7 @@ Ability to hotplug block devices has been added, which makes it possible to use
 
 ## How to check if container uses devicemapper block device as its rootfs
 
-Start a container. Call mount(8) within the container. You should see '/' mounted on /dev/vda device.
+Start a container. Call `mount(8)` within the container. You should see `/` mounted on `/dev/vda` device.
 
 # Devices
 
@@ -254,10 +254,10 @@ visibility and which is isolated from other groups.  VFIO uses this information
 to enforce safe ownership of devices for userspace. 
 
 You will need Intel VT-d capable hardware. Check if IOMMU is enabled in your host
-kernel by verifying `CONFIG_VFIO_NOIOMMU` is not in the kernel config. If it is set,
+kernel by verifying `CONFIG_VFIO_NOIOMMU` is not in the kernel configuration. If it is set,
 you will need to rebuild your kernel.
 
-The following kernel configs need to be enabled:
+The following kernel configuration options need to be enabled:
 ```
 CONFIG_VFIO_IOMMU_TYPE1=m 
 CONFIG_VFIO=m

virtcontainers/documentation/Developers.md

@@ -14,7 +14,6 @@ Table of Contents
 - docker
 - CNI
 - golang
-- gometalinter
 
 A number of these can be installed using the
 [virtcontainers-setup.sh](../utils/virtcontainers-setup.sh) script.

virtcontainers/documentation/api/1.0/api.md

@@ -779,14 +779,14 @@ type VCContainer interface {
 
 ### Container Functions
 
-* [CreateContainer](#createcontainer)
-* [DeleteContainer](#deletecontainer)
-* [StartContainer](#startcontainer)
-* [StopContainer](#stopcontainer)
-* [EnterContainer](#entercontainer)
-* [StatusContainer](#statuscontainer)
-* [KillContainer](#killcontainer)
-* [ProcessListContainer](#processlistcontainer)
+* [`CreateContainer`](#createcontainer)
+* [`DeleteContainer`](#deletecontainer)
+* [`StartContainer`](#startcontainer)
+* [`StopContainer`](#stopcontainer)
+* [`EnterContainer`](#entercontainer)
+* [`StatusContainer`](#statuscontainer)
+* [`KillContainer`](#killcontainer)
+* [`ProcessListContainer`](#processlistcontainer)
 
 #### `CreateContainer`
 ```Go

virtcontainers/experimental/README.md

@@ -38,8 +38,8 @@ the feature can be marked as "experimental" first, and users can test it manuall
 We make no guarantees about experimental features, they can be removed entirely at any point,
 or become non-experimental at some release, so relative configuration options can change radically.
 
-An experimental feature **MUST** have a descriptive name containing only lower-case characters, numbers or '_', 
-e.g. new_hypervisor_2, the name **MUST** be unique and will never be re-used in future.
+An experimental feature **MUST** have a descriptive name containing only lower-case characters, numbers or `_`, 
+e.g. `new_hypervisor_2`, the name **MUST** be unique and will never be re-used in future.
 
 ## What's the difference between "WIP" and "experimental"?
 

virtcontainers/persist/plugin/README.md

@@ -1,2 +1,2 @@
 This package is a simple placeholder currently which will contain persist storage plugin support,
-e.g. leveldb, sqlite and other possible storage implementations.
+e.g. LevelDB, SQLite and other possible storage implementations.