Skip to content
This repository was archived by the owner on May 3, 2024. It is now read-only.

Commit 739c0e5

Browse files
Fixed codacy formatting issues
Signed-off-by: Pratik Patil <[email protected]>
1 parent 9935bf1 commit 739c0e5

File tree

4 files changed

+30
-36
lines changed

4 files changed

+30
-36
lines changed

doc/FOPFOM-Programming-Guide.md

Lines changed: 16 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -71,7 +71,7 @@ Rather than sending individual items between Colibri services as separate RPCs,
7171

7272
## Sending a FOP
7373
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.
74-
```
74+
```C
7575
struct m0_fop {
7676
...
7777
/**
@@ -85,14 +85,14 @@ struct m0_fop {
8585
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.
8686

8787
**Define and initialize the fop_type ops**
88-
```
88+
```C
8989
const struct m0_fop_type_ops m0_rpc_fop_conn_establish_ops = {
9090
.fto_fom_init = &m0_rpc_fop_conn_establish_fom_init
9191
};
9292
```
9393

9494
**Define and initialize the rpc item_type ops**
95-
```
95+
```C
9696
static struct m0_rpc_item_type_ops default_item_type_ops = {
9797
.rito_encode = m0_rpc_fop_item_type_default_encode,
9898
.rito_decode = m0_rpc_fop_item_type_default_decode,
@@ -101,15 +101,16 @@ static struct m0_rpc_item_type_ops default_item_type_ops = {
101101
```
102102

103103
**Define and initialize the rpc item type**
104-
```
104+
```C
105105
m0_RPC_ITEM_TYPE_DEF(m0_rpc_item_conn_establish,
106106
m0_RPC_FOP_CONN_ESTABLISH_OPCODE,
107107
m0_RPC_ITEM_TYPE_REQUEST | m0_RPC_ITEM_TYPE_MUTABO,
108108
&default_item_type_ops);
109109
```
110110
111111
**Define and initialize the fop type for the new fop and associate the corresponding item type**
112-
```struct m0_fop_type m0_rpc_fop_conn_establish_fopt;
112+
```C
113+
struct m0_fop_type m0_rpc_fop_conn_establish_fopt;
113114
/* In module’s init function */
114115
foo_subsystem_init()
115116
{
@@ -127,7 +128,7 @@ A request FOP is sent by invoking a rpc routine m0_rpc_post(), and its correspon
127128
+ Client side
128129

129130
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:
130-
```
131+
```C
131132
system_call()->m0t1fs_sys_call()
132133
m0t2fs_sys_call() {
133134
/* create fop */
@@ -142,7 +143,7 @@ At server side a fop should be submitted to request handler for processing, invo
142143
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";
143144

144145
Example:
145-
```
146+
```C
146147
require "net/net_otw_types";
147148
require "addb/addbff/addb";
148149

@@ -214,7 +215,7 @@ Examples
214215
Consider the following write FOM example
215216

216217
Declaring FOP in reqh_ut_fom_xc.ff file
217-
```
218+
```C
218219
record {
219220
u64 f_seq;
220221
u64 f_oid
@@ -231,15 +232,15 @@ record {
231232
+ Defining and building a FOP
232233
233234
To build a particular FOP we need to define its corresponding m0_fop_type_ops and m0_fop_type structures as follows:
234-
```
235+
```C
235236
static struct m0_fop_type_ops reqh_ut_write_fop_ops = {
236237
.fto_fom_init = reqh_ut_io_fom_init,
237238
};
238239
239240
struct m0_fop_type reqh_ut_fom_io_write_fopt;
240241
```
241242
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.
242-
```
243+
```C
243244
/** Function to clean reqh ut io fops */
244245
void reqh_ut_fom_io_fop_fini(void)
245246
{
@@ -262,7 +263,7 @@ int reqh_ut_fom_io_fop_init(void)
262263
After defining and building a FOP as above, we can now define its corresponding FOM.
263264
264265
+ Defining FOM
265-
```
266+
```C
266267
static struct m0_fom_ops reqh_ut_write_fom_ops = {
267268
.fo_fini = reqh_ut_io_fom_fini
268269
.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 = {
271272
```
272273
**FOM type operations structure**
273274
FOM type operations structure
274-
```
275+
```C
275276
static const struct m0_fom_type_ops reqh_ut_write_fom_type_ops = {
276277
.fto_create = reqh_ut_write_fom_create,
277278
};
278279
```
279280

280281
FOM type structure, this is embedded inside struct m0_fop_type,
281-
```
282+
```C
282283
static struct m0_fom_type reqh_ut_write_fom_mopt = {
283284
.ft_ops = &reqh_ut_write_fom_type_ops,
284285
};
285286
```
286287
A typical fom state function would look something similar to this:
287-
```
288+
```C
288289
int reqh_ut_write_fom_state(struct m0_fom *fom
289290
{
290291
...
@@ -341,4 +342,4 @@ int reqh_ut_write_fom_state(struct m0_fom *fom
341342
}
342343
}
343344
```
344-
**Note:** For additional details on the implementation of above methods please refer to request handler UT code in reqh/ut/reqh_fom_ut.c
345+
**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

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -187,7 +187,7 @@ tx_close(tx);
187187
| :------------- | :------------- | :-------------|
188188
189189
190-
```
190+
```C
191191
count = 0;
192192
193193
cat = catalogue_get(req.cfid);
@@ -219,7 +219,7 @@ tx_close(tx);
219219
| NEXT | cfid, input: array of {key, nr} rc | output: array of { rec: array of { key, val } }
220220
| :------------- | :------------- | :---------------|
221221

222-
```
222+
```C
223223
count = 0;
224224

225225
cat = catalogue_get(req.cfid);
@@ -258,4 +258,4 @@ The detailed level design of the catalogue service should decide on use of rpc b
258258

259259
### Security model
260260

261-
None at the moment. Security model should be designed for all storage objects together.
261+
None at the moment. Security model should be designed for all storage objects together.

doc/Running_Motr_Across_a_Cluster.md

Lines changed: 4 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -52,12 +52,10 @@ This document provides information on how to build motr from source and then run
5252
other: 2 # max quantity of other Motr clients this host may have
5353
```
5454
> A single node CDF should look like this:
55-
55+
```yaml
5656
# Cluster Description File (CDF).
5757
# See `cfgen --help-schema` for the format description.
5858
nodes:
59-
60-
```yaml
6159
- hostname: ssu0 # [user@]hostname
6260
data_iface: ens33 # name of data network interface
6361
#data_iface_type: o2ib # type of network interface (optional);
@@ -104,12 +102,10 @@ This document provides information on how to build motr from source and then run
104102
# pools: [ the pool ]
105103
```
106104
> Whereas a CDF with 3 nodes should look like this:
107-
105+
```yaml
108106
# Cluster Description File (CDF).
109107
# See `cfgen --help-schema` for the format description.
110108
nodes:
111-
112-
```yaml
113109
- hostname: ssu0 # [user@]hostname
114110
data_iface: ens33 # name of data network interface
115111
#data_iface_type: o2ib # type of network interface (optional);
@@ -258,7 +254,7 @@ This document provides information on how to build motr from source and then run
258254

259255
8. ### Start the cluster:
260256
Run this at the main node, the first node (hostname) listed at the CDF.
261-
```sh
257+
```yaml
262258
hctl bootstrap --mkfs ~/CDF.yaml
263259
```
264260
9. ### Run I/O test:
@@ -275,6 +271,4 @@ This document provides information on how to build motr from source and then run
275271
- 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
276272
- 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).
277273
- Feb 22, 2021: Mayur Gupta ([email protected]) using CentOS 7.8.2003 on a Windows laptop running VMware Workstation.
278-
- Feb 10, 2021: Patrick Hession ([email protected]) using CentOS 7.8.2003 on a Windows laptop running Windows Hyper-V.
279-
280-
274+
- 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

Lines changed: 7 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -84,13 +84,11 @@ These parameters can be queried with one of the following options:
8484
8585
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
8686
87-
```
8887
- Run "motr/examples/setup_a_running_motr_system.sh" to setup a single node Motr, and parameters will be shown there.
89-
```
9088
9189
The first function to use Cortx Motr is to call m0\_client\_init():
9290
93-
```
91+
```C
9492
rc = m0_client_init(&m0_instance, &motr_conf, true);
9593
if (rc != 0) {
9694
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():
107105

108106
And as the final step, application needs to call m0\_client\_fini():
109107

110-
```
108+
```C
111109
m0_client_fini(m0_instance, true);
112110
```
113111
@@ -142,9 +140,9 @@ The steps to write to an existing object: function object\_write().
142140
* Open the object.
143141
* Allocate indexvec (struct m0\_indexvec), data buf (struct m0\_bufvec), attr buf (struct m0\_bufvec)
144142
145-
```
143+
`
146144
with specified count and block size. Please note, Motr I/O must be performed with multiple blocks with some 4K-aligned block size.
147-
```
145+
`
148146
149147
* Fill the indexvec with desired logical offset within the object, and correct buffer size.
150148
* Fill the data buf with your data.
@@ -163,9 +161,9 @@ The steps to read from an exiting object: function object\_read().
163161
* Open the object.
164162
* Allocate indexvec (struct m0\_indexvec), data buf (struct m0\_bufvec), attr buf (struct m0\_bufvec)
165163
166-
```
164+
`
167165
with specified count and block size. Please note, Motr I/O must be performed with multiple blocks with some 4K-aligned block size.
168-
```
166+
`
169167
170168
* Fill the indexvec with desired logical offset within the object, and correct buffer size.
171169
* 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
203201
204202
* Mar 17, 2022: Bo Wei ([email protected]) tested using CentOS 7.9.
205203
* Sep 28, 2021: Liana Valdes Rodriguez ([email protected] / [email protected]) tested using CentOS Linux release 7.8.2003 x86_64
204+

0 commit comments

Comments
 (0)