LUDOC-296 protocol: Rearrange presentation to be more top-down

[doc/protocol.git] / struct_obd_connect_data.txt

diff --git a/obd_connect_data.txt b/struct_obd_connect_data.txt
similarity index 99%
rename from obd_connect_data.txt
rename to struct_obd_connect_data.txt
index 0ca5076..ec0ccf7 100644 (file)
--- a/obd_connect_data.txt
+++ b/struct_obd_connect_data.txt
@@ -15,6 +15,7 @@ if the matching flag is set.  The server replies in 'ocd_connect_flags'
 with the subset of feature flags that it understands and intends to honour.
 The server may set fields in the reply for mutually-understood features.
 
+[source,c]
 ----
 struct obd_connect_data {
     __u64 ocd_connect_flags;
@@ -57,6 +58,7 @@ those flags (noted in comments above and the discussion below)
 actually control whether the remaining fields of 'obd_connect_data'
 get used.  The [[obd-connect-flags]] flags are:
 
+[source,c]
 ----
 #define OBD_CONNECT_RDONLY                0x1ULL /*client has read-only access*/
 #define OBD_CONNECT_INDEX                 0x2ULL /*connect specific LOV idx */
@@ -151,6 +153,7 @@ Lustre 1.4 and is mandatory for MDS_CONNECT RPCs. See also the discussion
 of inodes and extended attributes.
 [[mds-inode-bits-locks]]
 
+[source,c]
 ----
 #define MDS_INODELOCK_LOOKUP 0x000001  /* For namespace, dentry etc, and also
                                         * was used to protect permission (mode,
@@ -315,7 +318,7 @@ notify the server if client supports VBR.
 
 If the OBD_CONNECT_LOV_V3 is set if the client supports LOV_MAGIC_V3
 (0x0BD30BD0) style layouts. This type of the layout was introduced
-along with OST pools support and added the 'lov_mds_md_v3' layout. The
+along with OST pools support and added the 'lov_mds_md' layout. The
 OBD_CONNECT_LOV_V3 flag notifies a server if client supports
 this type of LOV EA to handle requests from it properly.