CORTX-33978- codacy cleanup: Fixed codacy formatting issues

doc/FOPFOM-Programming-Guide.md

@@ -71,7 +71,7 @@ Rather than sending individual items between Colibri services as separate RPCs,
 
 ## Sending a FOP
 A fop can be sent as a request FOP or a reply FOP. A fop is sent across using the various rpc interfaces. Every fop has an rpc item embedded into it.  
-```
+```C
 struct m0_fop {
       ...
       /**
@@ -85,14 +85,14 @@ struct m0_fop {
 Sending a fop involves initializing various fop and rpc item structures and then invoking the m0_rpc_post routines. The steps for the same are described below with few code examples.
 
 **Define and initialize the fop_type ops**   
-```
+```C
 const struct m0_fop_type_ops m0_rpc_fop_conn_establish_ops = {
       .fto_fom_init = &m0_rpc_fop_conn_establish_fom_init
 };  
 ```  
 
 **Define and initialize the rpc item_type ops**
-```
+```C
 static struct m0_rpc_item_type_ops default_item_type_ops = {
       .rito_encode = m0_rpc_fop_item_type_default_encode,
       .rito_decode = m0_rpc_fop_item_type_default_decode,
@@ -101,15 +101,16 @@ static struct m0_rpc_item_type_ops default_item_type_ops = {
 ```
 
 **Define and initialize the rpc item type**
-```
+```C
 m0_RPC_ITEM_TYPE_DEF(m0_rpc_item_conn_establish,
                  m0_RPC_FOP_CONN_ESTABLISH_OPCODE,
                  m0_RPC_ITEM_TYPE_REQUEST | m0_RPC_ITEM_TYPE_MUTABO,
                  &default_item_type_ops);  
 ```                 
 
 **Define and initialize the fop type for the new fop and associate the corresponding item type**
-```struct m0_fop_type m0_rpc_fop_conn_establish_fopt;
+```C
+struct m0_fop_type m0_rpc_fop_conn_establish_fopt;
 /* In module’s init function */
 foo_subsystem_init()
 {
@@ -127,7 +128,7 @@ A request FOP is sent by invoking a rpc routine m0_rpc_post(), and its correspon
 + Client side
 
 Every request fop should be submitted to request handler for processing (both at the client as well as at the server side) which is then forwarded by the request handler itself, although currently (for “november” demo) we do not have request handler at the client side. Thus sending a FOP from the client side just involves submitting it to rpc layer by invoking m0_rpc_post(). So, this may look something similar to this:    
-```
+```C
 system_call()->m0t1fs_sys_call()
 m0t2fs_sys_call() {
      /* create fop */
@@ -142,7 +143,7 @@ At server side a fop should be submitted to request handler for processing, invo
 The current format of fop operations need all fop formats referenced in the .ff file to be present in the same file. However with introduction of bulk IO client-server, there arises a need of referencing remote fops from one .ff file. Bulk IO transfer needs IO fop to contain a m0_net_buf_desc which is fop itself. ff2c compiler has a construct called “require” for this purpose. "require" statement introduces a dependency on other source file. For each "require", an #include directive is produced, which includes corresponding header file, "lib/vec.h" in this case require "lib/vec";
 
 Example:  
-```  
+```C  
 require "net/net_otw_types";
 require "addb/addbff/addb";
 
@@ -214,7 +215,7 @@ Examples
 Consider the following write FOM example
 
 Declaring FOP in reqh_ut_fom_xc.ff file
-```
+```C
 record {
         u64 f_seq;
         u64 f_oid
@@ -231,15 +232,15 @@ record {
 + Defining and building a FOP
 
 To build a particular FOP we need to define its corresponding m0_fop_type_ops and m0_fop_type structures as follows:  
-```  
+```C  
 static struct m0_fop_type_ops reqh_ut_write_fop_ops = {
        .fto_fom_init = reqh_ut_io_fom_init,
 };
 
 struct m0_fop_type reqh_ut_fom_io_write_fopt;
 ```  
 After defining the above structure, we need to have two subroutines(something like below) which actually builds the FOPs, and adds them to the global FOPs list.
-```
+```C
 /** Function to clean reqh ut io fops */
 void reqh_ut_fom_io_fop_fini(void)
 {
@@ -262,7 +263,7 @@ int reqh_ut_fom_io_fop_init(void)
 After defining and building a FOP as above, we can now define its corresponding FOM.
 
 + Defining FOM
-```
+```C
 static struct m0_fom_ops reqh_ut_write_fom_ops = {
       .fo_fini = reqh_ut_io_fom_fini
       .fo_state = reqh_ut_write_fom_state, (implements actual fom operation)
@@ -271,20 +272,20 @@ static struct m0_fom_ops reqh_ut_write_fom_ops = {
 ```
 **FOM type operations structure**
 FOM type operations structure
-```
+```C
 static const struct m0_fom_type_ops reqh_ut_write_fom_type_ops = {
       .fto_create = reqh_ut_write_fom_create,
 };
 ```
 
 FOM type structure, this is embedded inside struct m0_fop_type,
-```
+```C
 static struct m0_fom_type reqh_ut_write_fom_mopt = {
       .ft_ops = &reqh_ut_write_fom_type_ops,
 };  
 ```
 A typical fom state function would look something similar to this:
-```
+```C
 int reqh_ut_write_fom_state(struct m0_fom *fom
 {
         ...
@@ -341,4 +342,4 @@ int reqh_ut_write_fom_state(struct m0_fom *fom
         }
 }
 ```
-**Note:** For additional details on the implementation of above methods please refer to request handler UT code in reqh/ut/reqh_fom_ut.c
+**Note:** For additional details on the implementation of above methods please refer to request handler UT code in reqh/ut/reqh_fom_ut.c

doc/HLD-of-Catalogue-Service.md

@@ -187,7 +187,7 @@ tx_close(tx);
 | :------------- | :------------- | :-------------|
 
 
-```
+```C
 count = 0;
 
 cat = catalogue_get(req.cfid);
@@ -219,7 +219,7 @@ tx_close(tx);
 | NEXT    | cfid, input: array of {key, nr}	rc     | output: array of { rec: array of { key, val } }
 | :------------- | :------------- | :---------------|
 
-```	 
+```C	 
 count = 0;
 
 cat = catalogue_get(req.cfid);
@@ -258,4 +258,4 @@ The detailed level design of the catalogue service should decide on use of rpc b
 
 ### Security model
 
-None at the moment. Security model should be designed for all storage objects together.
+None at the moment. Security model should be designed for all storage objects together.

doc/Running_Motr_Across_a_Cluster.md

@@ -53,11 +53,10 @@ This document provides information on how to build motr from source and then run
             ```
             > A single node CDF should look like this:
 
+		```yaml
                 # Cluster Description File (CDF).
                 # See `cfgen --help-schema` for the format description.
                 nodes:
-
-                ```yaml
 	            - hostname: ssu0     # [user@]hostname
 	              data_iface: ens33        # name of data network interface
 	              #data_iface_type: o2ib  # type of network interface (optional);
@@ -104,12 +103,10 @@ This document provides information on how to build motr from source and then run
 	                 #    pools: [ the pool ]
                 ```
             > Whereas a CDF with 3 nodes should look like this:
-
+               ```yaml
                 # Cluster Description File (CDF).
                 # See `cfgen --help-schema` for the format description.
                 nodes:
-
-		```yaml
 	            - hostname: ssu0     # [user@]hostname
 	              data_iface: ens33        # name of data network interface
 	              #data_iface_type: o2ib  # type of network interface (optional);
@@ -258,7 +255,7 @@ This document provides information on how to build motr from source and then run
 
 8. ### Start the cluster:
     Run this at the main node, the first node (hostname) listed at the CDF.
-    ```sh
+    ```yaml
     hctl bootstrap --mkfs ~/CDF.yaml
     ```
 9. ### Run I/O test:
@@ -275,6 +272,4 @@ This document provides information on how to build motr from source and then run
 - Sep 15, 2021: Naga Kishore Kommuri ([email protected]) using CentOS Linux release 7.9.2009, verified with git tag CORTX-2.0.0-77 (#7d4d09cc9fd32ec7690c94298136b372069f3ce3) on main branch
 - Jul 2, 2021: Daniar Kurniawan ([email protected]) using CentOS 7.8.2003 on 4 bare-metal servers hosted by [Chameleon](https://www.chameleoncloud.org/) (node_type=Skylake).
 - Feb 22, 2021: Mayur Gupta ([email protected]) using CentOS 7.8.2003 on a Windows laptop running VMware Workstation.
-- Feb 10, 2021: Patrick Hession ([email protected]) using CentOS 7.8.2003 on a Windows laptop running Windows Hyper-V.
-
-
+- Feb 10, 2021: Patrick Hession ([email protected]) using CentOS 7.8.2003 on a Windows laptop running Windows Hyper-V.

doc/motr-object-app.md

@@ -84,13 +84,11 @@ These parameters can be queried with one of the following options:
 
 If you've followed these instructions [Cluster Setup](https://github.com/Seagate/Cortx/blob/main/doc/Cluster_Setup.md) or [Quick Start Guide](/doc/Quick-Start-Guide.rst) to setup a Cortx Motr system. Or
 
-```
 - Run "motr/examples/setup_a_running_motr_system.sh" to setup a single node Motr, and parameters will be shown there.
-```
 
 The first function to use Cortx Motr is to call m0\_client\_init():
 
-```
+```C
     rc = m0_client_init(&m0_instance, &motr_conf, true);
     if (rc != 0) {
             printf("error in m0_client_init: %d\n", rc);
@@ -107,7 +105,7 @@ The first function to use Cortx Motr is to call m0\_client\_init():
 
 And as the final step, application needs to call m0\_client\_fini():
 
-```
+```C
     m0_client_fini(m0_instance, true);
 ```
 
@@ -142,9 +140,9 @@ The steps to write to an existing object: function object\_write().
 *   Open the object.
 *   Allocate indexvec (struct m0\_indexvec), data buf (struct m0\_bufvec), attr buf (struct m0\_bufvec)
 
-```
+`
        with specified count and block size. Please note, Motr I/O must be performed with multiple blocks with some 4K-aligned block size.
-```
+`
 
 *   Fill the indexvec with desired logical offset within the object, and correct buffer size.
 *   Fill the data buf with your data.
@@ -163,9 +161,9 @@ The steps to read from an exiting object: function object\_read().
 *   Open the object.
 *   Allocate indexvec (struct m0\_indexvec), data buf (struct m0\_bufvec), attr buf (struct m0\_bufvec)
 
-```
+`
        with specified count and block size. Please note, Motr I/O must be performed with multiple blocks with some 4K-aligned block size.
-```
+`
 
 *   Fill the indexvec with desired logical offset within the object, and correct buffer size.
 *   Init the read operation with m0\_obj\_op().
@@ -203,3 +201,4 @@ If run `example1` and encounter error "obj_id invalid. Please refer to M0_ID_APP
 
 *   Mar 17, 2022: Bo Wei ([email protected]) tested using CentOS 7.9.
 *   Sep 28, 2021: Liana Valdes Rodriguez ([email protected] / [email protected]) tested using CentOS Linux release 7.8.2003 x86_64
+