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

[doc/protocol.git] / ldlm_resource_desc.txt

diff --git a/ldlm_resource_desc.txt b/ldlm_resource_desc.txt
deleted file mode 100644 (file)
index 2b48f31..0000000
--- a/ldlm_resource_desc.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-LDLM Resource Descriptor
-^^^^^^^^^^^^^^^^^^^^^^^^
-[[struct-ldlm-resource-desc]]
-
-The resource descriptor identifies the individual resource that is
-being locked, along with what sort of thing it is.
-
-----
-struct ldlm_resource_desc {
-        struct ldlm_type lr_type;
-        __u32 lr_padding;       /* also fix lustre_swab_ldlm_resource_desc */
-        struct ldlm_res_id lr_name;
-};
-----
-
-The 'lr_type' field identifies one of the four types of lock that
-might be placed on a resource. A "plain" lock type just locks a
-particular resource. An "extent" lock type only locks a contiguous
-sequence of byte offsets within a regular file. An "flock" lock type
-represents an application layer advisory lock from the 'flock()'
-system call. While Lustre manages "flock" types locks on behalf of the
-application, they do not affect Lustre operation.  An "ibits" lock
-type allows fine grained locking of different parts of a single
-resource. A single lock request or cancellation may operate on one or
-more lock bits, or individual lock bits may be granted on the same
-resource separately.  See also <<ldlm-wire-policy-data-t>>.  A lock
-descriptor may also have no type at all, in which case the 'lr_type'
-field is 0, meaning "no lock".
-
-The 'lr_name' field identifies (by name) the resource(s) that are the
-objects of the locking operation. See the discussion of
-<<struct-ldlm-res-id>>.
-
-----
-enum ldlm_type {
-        LDLM_PLAIN     = 10,
-        LDLM_EXTENT    = 11,
-        LDLM_FLOCK     = 12,
-        LDLM_IBITS     = 13,
-};
-----
-[[struct-ldlm-type]]