markdownlint: enable rule MD032

MD032 - Lists should be surrounded by blank lines
Fixed all errors

Signed-off-by: Maciej Wawryk <maciejx.wawryk@intel.com>
Change-Id: Idd18d38386c0150f5d68068a59717a34d4e1d991
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/9142
Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>

CHANGELOG.md

@@ -173,6 +173,7 @@ Added the `nvmf_set_crdt` RPC for setting command retry delay times.
 Expanded `spdk_nvmf_poll_group_stat` with current qpair count statistics.
 
 Removed following deprecated APIs:
+
 - `spdk_nvmf_poll_group_get_stat` (function in `nvmf.h`),
 - `spdk_nvmf_transport_poll_group_get_stat` (function in `nvmf.h`),
 - `spdk_nvmf_transport_poll_group_free_stat`(function in `nvmf.h`),
@@ -405,6 +406,7 @@ use `disable-zerocopy-send-server` or `disable-zerocopy-send-client` instead.
 
 Added cmd_parser.py used to parse the args from argparse. There are
 two benefit to use command parser:
+
 - Simplify the definition of rpc method. It will reduce the rpc method code.
 - Make the rpc call more versatile. User can add private args into rpc method.
 

doc/bdevperf.md

@@ -73,6 +73,7 @@ length    | 100% of bdev size | End I/O at `offset`+`length` on the bdev
 rw        |                   | Type of I/O pattern
 
 Available rw types:
+
 - read
 - randread
 - write

doc/libraries.md

@@ -22,19 +22,19 @@ are contained in the `module` directory.
 The libraries in the `lib` directory can be readily divided into four categories:
 
 - Utility Libraries: These libraries contain basic, commonly used functions that make more complex
-libraries easier to implement. For example, `spdk_log` contains macro definitions that provide a
-consistent logging paradigm and `spdk_json` is a general purpose JSON parsing library.
+  libraries easier to implement. For example, `spdk_log` contains macro definitions that provide a
+  consistent logging paradigm and `spdk_json` is a general purpose JSON parsing library.
 - Protocol Libraries: These libraries contain the building blocks for a specific service. For example,
-`spdk_nvmf` and `spdk_vhost` each define the storage protocols after which they are named.
+  `spdk_nvmf` and `spdk_vhost` each define the storage protocols after which they are named.
 - Storage Service Libraries: These libraries provide a specific abstraction that can be mapped to somewhere
-between the physical drive and the filesystem level of your typical storage stack. For example `spdk_bdev`
-provides a general block device abstraction layer, `spdk_lvol` provides a logical volume abstraction,
-`spdk_blobfs` provides a filesystem abstraction, and `spdk_ftl` provides a flash translation layer
-abstraction.
+  between the physical drive and the filesystem level of your typical storage stack. For example `spdk_bdev`
+  provides a general block device abstraction layer, `spdk_lvol` provides a logical volume abstraction,
+  `spdk_blobfs` provides a filesystem abstraction, and `spdk_ftl` provides a flash translation layer
+  abstraction.
 - System Libraries: These libraries provide system level services such as a JSON based RPC service
-(see `spdk_jsonrpc`) and thread abstractions (see `spdk_thread`). The most notable library in this category
-is the `spdk_env_dpdk` library which provides a shim for the underlying Data Plane Development Kit (DPDK)
-environment and provides services like memory management.
+  (see `spdk_jsonrpc`) and thread abstractions (see `spdk_thread`). The most notable library in this category
+  is the `spdk_env_dpdk` library which provides a shim for the underlying Data Plane Development Kit (DPDK)
+  environment and provides services like memory management.
 
 The one library in the `lib` directory that doesn't fit into the above classification is the `spdk_event` library.
 This library defines a framework used by the applications contained in the `app` and `example` directories. Much
@@ -58,10 +58,10 @@ There are seven sub-directories in the `module` directory which each hold a diff
 sub-directories can be divided into two types.
 
 - plug-in libraries: These libraries are explicitly tied to one of the libraries in the `lib` directory and
-are registered with that library at runtime by way of a specific constructor function. The parent library in
-the `lib` directory then manages the module directly. These types of libraries each implement a function table
-defined by their parent library. The following table shows these directories and their corresponding parent
-libraries:
+  are registered with that library at runtime by way of a specific constructor function. The parent library in
+  the `lib` directory then manages the module directly. These types of libraries each implement a function table
+  defined by their parent library. The following table shows these directories and their corresponding parent
+  libraries:
 
 <center>
 | module directory | parent library | dependent on event library |
@@ -73,9 +73,9 @@ libraries:
 </center>
 
 - Free libraries: These libraries are highly dependent upon a library in the `lib` directory but are not
-explicitly registered to that library via a constructor. The libraries in the `blob`, `blobfs`, and `env_dpdk`
-directories fall into this category. None of the libraries in this category depend explicitly on the
-`spdk_event` library.
+  explicitly registered to that library via a constructor. The libraries in the `blob`, `blobfs`, and `env_dpdk`
+  directories fall into this category. None of the libraries in this category depend explicitly on the
+  `spdk_event` library.
 
 ## Library Conventions {#conventions}
 
@@ -149,15 +149,15 @@ which is a linker script. It simply contains references to all of the other spdk
 There are essentially two ways of linking to SPDK libraries.
 
 1. An application can link to the top level shared object library as follows:
-~~~{.sh}
+   ~~~{.sh}
 	gcc -o my_app ./my_app.c -lspdk -lspdk_env_dpdk -ldpdk
-~~~
+   ~~~
 
 2. An application can link to only a subset of libraries by linking directly to the ones it relies on:
-~~~{.sh}
+   ~~~{.sh}
 	gcc -o my_app ./my_app.c -lpassthru_external -lspdk_event_bdev -lspdk_bdev -lspdk_bdev_malloc
 	-lspdk_log -lspdk_thread -lspdk_util -lspdk_event -lspdk_env_dpdk -ldpdk
-~~~
+   ~~~
 
 In the second instance, please note that applications need only link to the libraries upon which they
 directly depend. All SPDK libraries have their dependencies specified at object compile time. This means

doc/spdk_top.md

@@ -32,7 +32,7 @@ Menu at the bottom of SPDK top window shows many options for changing displayed
 * Quit - quits the SPDK top application.
 * Switch tab - allows to select THREADS/POLLERS/CORES tabs.
 * Previous page/Next page - scrolls up/down to the next set of rows displayed. Indicator in the bottom-left corner shows current page and number
-of all available pages.
+  of all available pages.
 * Item details - displays details pop-up window for highlighted data row. Selection is changed by pressing UP and DOWN arrow keys.
 * Help - displays help pop-up window.
 

mdl_rules.rb

@@ -6,7 +6,6 @@ rule 'MD013', :line_length => 170
 exclude_rule 'MD024'
 rule 'MD029', :style => "ordered"
 exclude_rule 'MD031'
-exclude_rule 'MD032'
 exclude_rule 'MD033'
 exclude_rule 'MD034'
 exclude_rule 'MD035'

test/app/fuzz/iscsi_fuzz/README.md

@@ -8,6 +8,7 @@ randomized PDU commands through a simulated iSCSI initiator.
 1. iSCSI initiator send a login request PDU to iSCSI Target. Once a session is connected,
 2. iSCSI initiator send huge amount and random PDUs continuously to iSCSI Target.
 3. iSCSI initiator send a logout request PDU to iSCSI Target in the end.
+
 Especially, iSCSI initiator need to build different bhs according to different bhs opcode.
 Then iSCSI initiator will receive all kinds of responsed opcodes from iSCSI Target.
 The application will terminate when run time expires (see the -t flag).
@@ -15,8 +16,10 @@ The application will terminate when run time expires (see the -t flag).
 ## Output
 
 By default, the fuzzer will print commands that:
+
 1. Complete successfully back from the target, or
 2. Are outstanding at the time of a connection error occurs.
+
 Commands are dumped as named objects in json format which can then be supplied back to the
 script for targeted debugging on a subsequent run.