doc: remove mentions of legacy config

Support for legacy configuration has been removed from SPDK
at this point.

This patch focuses on adjustement in documentation and examples.

Signed-off-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
Change-Id: Icfe8baf7a7497ffa86fde9038001429c5a7bc4f6
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/4801
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Aleksey Marchuk <alexeymar@mellanox.com>
Reviewed-by: Paul Luse <paul.e.luse@intel.com>

doc/applications.md

@@ -49,11 +49,8 @@ Param    | Long Param             | Type     | Default                | Descript
 
 ### Configuration file {#cmd_arg_config_file}
 
-Historically, the SPDK applications were configured using a configuration file.
+SPDK applications are configured using a JSON RPC configuration file.
-This is still supported, but is considered deprecated in favor of JSON RPC
+See @ref jsonrpc for details.
-configuration. See @ref jsonrpc for details.
-
-Note that `--config` and `--wait-for-rpc` cannot be used at the same time.
 
 ### Limit coredump {#cmd_arg_limit_coredump}
 

doc/bdev_module.md

@@ -153,7 +153,7 @@ the I/O to other block devices. The canonical example would be a bdev module
 that implements RAID. Virtual bdevs are created in the same way as regular
 bdevs, but take one additional step. The module can look up the underlying
 bdevs it wishes to route I/O to using spdk_bdev_get_by_name(), where the string
-name is provided by the user in a configuration file or via an RPC. The module
+name is provided by the user via an RPC. The module
 then may proceed is normal by opening the bdev to obtain a descriptor, and
 creating I/O channels for the bdev (probably in response to the
 `get_io_channel` callback). The final step is to have the module use its open

doc/blobfs.md

@@ -37,7 +37,7 @@ export USE_RTTI=1 && make db_bench DEBUG_LEVEL=0 SPDK_DIR=path/to/spdk
 Create an NVMe section in the configuration file using SPDK's `gen_nvme.sh` script.
 
 ~~~{.sh}
-scripts/gen_nvme.sh > /usr/local/etc/spdk/rocksdb.conf
+scripts/gen_nvme.sh > /usr/local/etc/spdk/rocksdb.json
 ~~~
 
 Verify the configuration file has specified the correct NVMe SSD.
@@ -54,7 +54,7 @@ HUGEMEM=5120 scripts/setup.sh
 Create an empty SPDK blobfs for testing.
 
 ~~~{.sh}
-test/blobfs/mkfs/mkfs /usr/local/etc/spdk/rocksdb.conf Nvme0n1
+test/blobfs/mkfs/mkfs /usr/local/etc/spdk/rocksdb.json Nvme0n1
 ~~~
 
 At this point, RocksDB is ready for testing with SPDK.  Three `db_bench` parameters are used to configure SPDK:
@@ -74,7 +74,7 @@ BlobFS provides a FUSE plug-in to mount an SPDK BlobFS as a kernel filesystem fo
 The FUSE plug-in requires fuse3 and will be built automatically when fuse3 is detected on the system.
 
 ~~~{.sh}
-test/blobfs/fuse/fuse /usr/local/etc/spdk/rocksdb.conf Nvme0n1 /mnt/fuse
+test/blobfs/fuse/fuse /usr/local/etc/spdk/rocksdb.json Nvme0n1 /mnt/fuse
 ~~~
 
 Note that the FUSE plug-in has some limitations - see the list below.

doc/iscsi.md

@@ -23,24 +23,6 @@ document.
 
 ![iSCSI structure](iscsi.svg)
 
-## Configuring iSCSI Target via config file {#iscsi_config}
-
-A `iscsi_tgt` specific configuration file is used to configure the iSCSI target. A fully documented
-example configuration file is located at `etc/spdk/iscsi.conf.in`.
-
-The configuration file is used to configure the SPDK iSCSI target. This file defines the following:
-TCP ports to use as iSCSI portals; general iSCSI parameters; initiator names and addresses to allow
-access to iSCSI target nodes; number and types of storage backends to export over iSCSI LUNs; iSCSI
-target node mappings between portal groups, initiator groups, and LUNs.
-
-You should make a copy of the example configuration file, modify it to suit your environment, and
-then run the iscsi_tgt application and pass it the configuration file using the -c option. Right now,
-the target requires elevated privileges (root) to run.
-
-~~~
-build/bin/iscsi_tgt -c /path/to/iscsi.conf
-~~~
-
 ### Assigning CPU Cores to the iSCSI Target {#iscsi_config_lcore}
 
 SPDK uses the [DPDK Environment Abstraction Layer](http://dpdk.org/doc/guides/prog_guide/env_abstraction_layer.html)
@@ -57,26 +39,9 @@ command line option is used to configure the SPDK iSCSI target:
 This is a hexadecimal bit mask of the CPU cores where the iSCSI target will start polling threads.
 In this example, CPU cores 24, 25, 26 and 27 would be used.
 
-### Configuring a LUN in the iSCSI Target {#iscsi_lun}
-
-Each LUN in an iSCSI target node is associated with an SPDK block device.  See @ref bdev
-for details on configuring SPDK block devices.  The block device to LUN mappings are specified in the
-configuration file as:
-
-~~~~
-[TargetNodeX]
-  LUN0 Malloc0
-  LUN1 Nvme0n1
-~~~~
-
-This exports a malloc'd target. The disk is a RAM disk that is a chunk of memory allocated by iscsi in
-user space. It will use offload engine to do the copy job instead of memcpy if the system has enough DMA
-channels.
-
 ## Configuring iSCSI Target via RPC method {#iscsi_rpc}
 
-In addition to the configuration file, the iSCSI target may also be configured via JSON-RPC calls. See
+The iSCSI target is configured via JSON-RPC calls. See @ref jsonrpc for details.
-@ref jsonrpc for details.
 
 ### Portal groups
 

doc/spdkcli.md

@@ -18,7 +18,7 @@ Package dependencies at the moment include:
 
 ~~~{.sh}
 ./scripts/setup.sh
-./build/bin/vhost -c vhost.conf
+./build/bin/vhost -c vhost.json
 ~~~
 
 ### Run SPDK CLI

doc/vmd.md

@@ -79,12 +79,6 @@ $ ./scripts/rpc.py bdev_nvme_attach_controller -b NVMe1 -t PCIe -a 5d0505:01:00.
 
 When application framework is used, VMD section needs to be added to the configuration file:
 
-Text config:
-```
-[VMD]
-  Enable True
-```
-
 JSON config:
 ```
 {

examples/bdev/fio_plugin/README.md

@@ -51,9 +51,6 @@ The fio configuration file must contain one new parameter:
 
     spdk_json_conf=./examples/bdev/fio_plugin/bdev.json
 
-This must point at an SPDK configuration file. There are a number of example configuration
-files in the SPDK repository under etc/spdk.
-
 You can specify which block device to run against by setting the filename parameter
 to the block device name:
 

examples/bdev/fio_plugin/full_bench.fio

@@ -1,6 +1,6 @@
 [global]
 ioengine=spdk_bdev
-spdk_conf=./examples/bdev/fio_plugin/bdev.conf.in
+spdk_conf=./examples/bdev/fio_plugin/bdev.json
 thread=1
 group_reporting=1
 direct=1