All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Linux Doc Mailing List <linux-doc@vger.kernel.org>,
	Jonathan Corbet <corbet@lwn.net>
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	"Theodore Y. Ts'o" <tytso@mit.edu>,
	Eric Biggers <ebiggers@kernel.org>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	linux-fscrypt@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH v4 35/52] docs: fs: fscrypt.rst: get rid of :c:type: tags
Date: Wed, 30 Sep 2020 15:24:58 +0200	[thread overview]
Message-ID: <689d790237b64fc7d81fcf97ac303cc1dbdd33d4.1601467849.git.mchehab+huawei@kernel.org> (raw)
In-Reply-To: <cover.1601467849.git.mchehab+huawei@kernel.org>

The :c:type: tag has problems with Sphinx 3.x, as structs
there should be declared with c:struct.

So, remove them, relying at automarkup.py extension to
convert them into cross-references.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/filesystems/fscrypt.rst | 51 ++++++++++++---------------
 1 file changed, 23 insertions(+), 28 deletions(-)

diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst
index 4f858b38a412..46a9d1bd2ab5 100644
--- a/Documentation/filesystems/fscrypt.rst
+++ b/Documentation/filesystems/fscrypt.rst
@@ -437,8 +437,7 @@ FS_IOC_SET_ENCRYPTION_POLICY
 The FS_IOC_SET_ENCRYPTION_POLICY ioctl sets an encryption policy on an
 empty directory or verifies that a directory or regular file already
 has the specified encryption policy.  It takes in a pointer to a
-struct fscrypt_policy_v1 or a :c:type:`struct
-fscrypt_policy_v2`, defined as follows::
+struct fscrypt_policy_v1 or a struct fscrypt_policy_v2, defined as follows::
 
     #define FSCRYPT_POLICY_V1               0
     #define FSCRYPT_KEY_DESCRIPTOR_SIZE     8
@@ -464,11 +463,10 @@ fscrypt_policy_v2`, defined as follows::
 
 This structure must be initialized as follows:
 
-- ``version`` must be FSCRYPT_POLICY_V1 (0) if the struct is
-  :c:type:`fscrypt_policy_v1` or FSCRYPT_POLICY_V2 (2) if the struct
-  is :c:type:`fscrypt_policy_v2`.  (Note: we refer to the original
-  policy version as "v1", though its version code is really 0.)  For
-  new encrypted directories, use v2 policies.
+- ``version`` must be FSCRYPT_POLICY_V1 (0) if struct fscrypt_policy_v1
+  is used or FSCRYPT_POLICY_V2 (2) if struct fscrypt_policy_v2 is used.
+  (Note: we refer to the original policy version as "v1", though its
+  version code is really 0.)  For new encrypted directories, use v2 policies.
 
 - ``contents_encryption_mode`` and ``filenames_encryption_mode`` must
   be set to constants from ``<linux/fscrypt.h>`` which identify the
@@ -509,8 +507,7 @@ This structure must be initialized as follows:
   be arbitrarily chosen.  Instead, the key must first be added using
   `FS_IOC_ADD_ENCRYPTION_KEY`_.  Then, the ``key_spec.u.identifier``
   the kernel returned in the struct fscrypt_add_key_arg must
-  be used as the ``master_key_identifier`` in the :c:type:`struct
-  fscrypt_policy_v2`.
+  be used as the ``master_key_identifier`` in struct fscrypt_policy_v2.
 
 If the file is not yet encrypted, then FS_IOC_SET_ENCRYPTION_POLICY
 verifies that the file is an empty directory.  If so, the specified
@@ -637,9 +634,8 @@ The FS_IOC_GET_ENCRYPTION_POLICY ioctl can also retrieve the
 encryption policy, if any, for a directory or regular file.  However,
 unlike `FS_IOC_GET_ENCRYPTION_POLICY_EX`_,
 FS_IOC_GET_ENCRYPTION_POLICY only supports the original policy
-version.  It takes in a pointer directly to a :c:type:`struct
-fscrypt_policy_v1` rather than a :c:type:`struct
-fscrypt_get_policy_ex_arg`.
+version.  It takes in a pointer directly to struct fscrypt_policy_v1
+rather than struct fscrypt_get_policy_ex_arg.
 
 The error codes for FS_IOC_GET_ENCRYPTION_POLICY are the same as those
 for FS_IOC_GET_ENCRYPTION_POLICY_EX, except that
@@ -717,10 +713,9 @@ as follows:
   ``key_spec.type`` must contain FSCRYPT_KEY_SPEC_TYPE_DESCRIPTOR, and
   ``key_spec.u.descriptor`` must contain the descriptor of the key
   being added, corresponding to the value in the
-  ``master_key_descriptor`` field of :c:type:`struct
-  fscrypt_policy_v1`.  To add this type of key, the calling process
-  must have the CAP_SYS_ADMIN capability in the initial user
-  namespace.
+  ``master_key_descriptor`` field of struct fscrypt_policy_v1.
+  To add this type of key, the calling process must have the
+  CAP_SYS_ADMIN capability in the initial user namespace.
 
   Alternatively, if the key is being added for use by v2 encryption
   policies, then ``key_spec.type`` must contain
@@ -737,8 +732,8 @@ as follows:
 
 - ``key_id`` is 0 if the raw key is given directly in the ``raw``
   field.  Otherwise ``key_id`` is the ID of a Linux keyring key of
-  type "fscrypt-provisioning" whose payload is a :c:type:`struct
-  fscrypt_provisioning_key_payload` whose ``raw`` field contains the
+  type "fscrypt-provisioning" whose payload is
+  struct fscrypt_provisioning_key_payload whose ``raw`` field contains the
   raw key and whose ``type`` field matches ``key_spec.type``.  Since
   ``raw`` is variable-length, the total size of this key's payload
   must be ``sizeof(struct fscrypt_provisioning_key_payload)`` plus the
@@ -956,8 +951,8 @@ FS_IOC_GET_ENCRYPTION_KEY_STATUS
 The FS_IOC_GET_ENCRYPTION_KEY_STATUS ioctl retrieves the status of a
 master encryption key.  It can be executed on any file or directory on
 the target filesystem, but using the filesystem's root directory is
-recommended.  It takes in a pointer to a :c:type:`struct
-fscrypt_get_key_status_arg`, defined as follows::
+recommended.  It takes in a pointer to struct fscrypt_get_key_status_arg,
+defined as follows::
 
     struct fscrypt_get_key_status_arg {
             /* input */
@@ -1148,12 +1143,12 @@ Implementation details
 Encryption context
 ------------------
 
-An encryption policy is represented on-disk by a :c:type:`struct
-fscrypt_context_v1` or a struct fscrypt_context_v2.  It is
-up to individual filesystems to decide where to store it, but normally
-it would be stored in a hidden extended attribute.  It should *not* be
-exposed by the xattr-related system calls such as getxattr() and
-setxattr() because of the special semantics of the encryption xattr.
+An encryption policy is represented on-disk by struct fscrypt_context_v1
+or struct fscrypt_context_v2.  It is up to individual filesystems to decide
+where to store it, but normally it would be stored in a hidden extended
+attribute.  It should *not* be exposed by the xattr-related system calls
+such as getxattr() and setxattr() because of the special semantics of the
+encryption xattr.
 (In particular, there would be much confusion if an encryption policy
 were to be added to or removed from anything other than an empty
 directory.)  These structs are defined as follows::
@@ -1249,8 +1244,8 @@ a strong "hash" of the ciphertext filename, along with the optional
 filesystem-specific hash(es) needed for directory lookups.  This
 allows the filesystem to still, with a high degree of confidence, map
 the filename given in ->lookup() back to a particular directory entry
-that was previously listed by readdir().  See :c:type:`struct
-fscrypt_nokey_name` in the source for more details.
+that was previously listed by readdir().  See struct fscrypt_nokey_name
+in the source for more details.
 
 Note that the precise way that filenames are presented to userspace
 without the key is subject to change in the future.  It is only meant
-- 
2.26.2


  parent reply	other threads:[~2020-09-30 13:27 UTC|newest]

Thread overview: 103+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-30 13:24 [PATCH v4 00/52] Fix html build with Sphinx 3.1 and above Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 01/52] docs: cdomain.py: add support for a new Sphinx 3.1+ tag Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 02/52] docs: cdomain.py: extend it to handle new Sphinx 3.x tags Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 03/52] docs: conf.py: disable automarkup for Sphinx 3.x Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 04/52] scripts: kernel-doc: make it more compatible with " Mauro Carvalho Chehab
2020-10-01 21:41   ` Jonathan Corbet
2020-10-01 23:02     ` Jonathan Corbet
2020-10-02  6:22     ` Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 05/52] scripts: kernel-doc: use a less pedantic markup for funcs on " Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 06/52] scripts: kernel-doc: fix troubles with line counts Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 07/52] scripts: kernel-doc: reimplement -nofunction argument Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 08/52] scripts: kernel-doc: fix typedef identification Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 09/52] scripts: kernel-doc: don't mangle with parameter list Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 10/52] docs: kerneldoc.py: append the name of the parsed doc file Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 11/52] docs: kerneldoc.py: add support for kerneldoc -nosymbol Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 12/52] media: docs: make CEC documents compatible with Sphinx 3.1+ Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 13/52] media: docs: make V4L documents more " Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 14/52] media: docs: make DVB " Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 15/52] media: docs: make MC " Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 16/52] media: docs: make RC " Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 17/52] media: cec-core.rst: don't use c:type for structs Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 18/52] math64.h: kernel-docs: Convert some markups into normal comments Mauro Carvalho Chehab
2020-09-30 13:46   ` Vincenzo Frascino
2020-09-30 13:24 ` [PATCH v4 19/52] memblock: get rid of a :c:type leftover Mauro Carvalho Chehab
2020-09-30 14:23   ` Mike Rapoport
2020-09-30 15:13     ` Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 20/52] drm: drm_dsc.h: fix a kernel-doc markup Mauro Carvalho Chehab
2020-09-30 13:24   ` Mauro Carvalho Chehab
2020-09-30 14:42   ` Daniel Vetter
2020-09-30 14:42     ` Daniel Vetter
2020-09-30 13:24 ` [PATCH v4 21/52] docs: remove some replace macros like |struct foo| Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 22/52] docs: get rid of :c:type explicit declarations for structs Mauro Carvalho Chehab
2020-09-30 13:24   ` Mauro Carvalho Chehab
2020-09-30 14:26   ` Mike Rapoport
2020-09-30 14:26     ` Mike Rapoport
2020-09-30 15:01   ` Takashi Iwai
2020-09-30 15:01     ` Takashi Iwai
2020-09-30 16:50   ` André Almeida
2020-09-30 16:50     ` André Almeida
2020-09-30 13:24 ` [PATCH v4 23/52] docs: trace-uses.rst: remove bogus c-domain tags Mauro Carvalho Chehab
2020-09-30 16:35   ` Steven Rostedt
2020-10-01  6:06   ` Kamalesh Babulal
2020-10-01  6:41     ` Mauro Carvalho Chehab
2020-10-01  8:27       ` Kamalesh Babulal
2020-09-30 13:24 ` [PATCH v4 24/52] docs: it_IT: fix namespace collisions at locking.rst Mauro Carvalho Chehab
2020-10-01 12:04   ` Federico Vaga
2020-09-30 13:24 ` [PATCH v4 25/52] docs: net: ieee802154.rst: fix C expressions Mauro Carvalho Chehab
2020-09-30 21:23   ` David Miller
2020-09-30 13:24 ` [PATCH v4 26/52] docs: genericirq.rst: don't document chip.c functions twice Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 27/52] docs: kernel-api.rst: drop kernel/irq/manage.c kernel-doc tag Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 28/52] docs: remove sound API duplication Mauro Carvalho Chehab
2020-09-30 13:24   ` Mauro Carvalho Chehab
2020-09-30 14:57   ` Takashi Iwai
2020-09-30 14:57     ` Takashi Iwai
2020-09-30 13:24 ` [PATCH v4 29/52] docs: basics.rst: move kernel-doc workqueue markups to workqueue.rst Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 30/52] docs: scsi: target.rst: remove iSCSI transport class kernel-doc markup Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 31/52] docs: device_link.rst: remove duplicated kernel-doc include Mauro Carvalho Chehab
2020-09-30 21:03   ` Saravana Kannan
2020-09-30 13:24 ` [PATCH v4 32/52] docs: basics.rst: get rid of rcu kernel-doc macros Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 33/52] docs: net: statistics.rst: remove a duplicated kernel-doc Mauro Carvalho Chehab
2020-09-30 21:23   ` David Miller
2020-09-30 13:24 ` [PATCH v4 34/52] docs: pstore-blk.rst: fix kernel-doc tags Mauro Carvalho Chehab
2020-09-30 23:23   ` Kees Cook
2020-09-30 13:24 ` Mauro Carvalho Chehab [this message]
2020-09-30 16:21   ` [PATCH v4 35/52] docs: fs: fscrypt.rst: get rid of :c:type: tags Eric Biggers
2020-09-30 16:53     ` Mauro Carvalho Chehab
2020-09-30 17:06       ` Eric Biggers
2020-10-05 12:06         ` Mauro Carvalho Chehab
2020-10-05 19:08           ` Eric Biggers
2020-10-06  8:23             ` Mauro Carvalho Chehab
2020-09-30 13:24 ` [PATCH v4 36/52] docs: devices.rst: get rid of :c:type macros Mauro Carvalho Chehab
2020-09-30 13:25 ` [PATCH v4 37/52] docs: sound: writing-an-alsa-driver.rst: get rid of :c:type Mauro Carvalho Chehab
2020-09-30 13:25   ` Mauro Carvalho Chehab
2020-09-30 14:59   ` Takashi Iwai
2020-09-30 14:59     ` Takashi Iwai
2020-09-30 13:25 ` [PATCH v4 38/52] docs: block: typec_bus.rst: " Mauro Carvalho Chehab
2020-09-30 16:48   ` André Almeida
2020-09-30 13:25 ` [PATCH v4 39/52] docs: writing-an-alsa-driver.rst: fix some bad c:func: markups Mauro Carvalho Chehab
2020-09-30 13:25   ` Mauro Carvalho Chehab
2020-09-30 14:58   ` Takashi Iwai
2020-09-30 14:58     ` Takashi Iwai
2020-09-30 13:25 ` [PATCH v4 40/52] docs: fpga: replace :c:member: macros Mauro Carvalho Chehab
2020-09-30 23:46   ` Moritz Fischer
2020-09-30 13:25 ` [PATCH v4 41/52] docs: kgdb.rst: fix :c:type: usages Mauro Carvalho Chehab
2020-10-01 11:29   ` Daniel Thompson
2020-09-30 13:25 ` [PATCH v4 42/52] docs: libata.rst: fix a wrong usage of :c:type: tag Mauro Carvalho Chehab
2020-09-30 13:25 ` [PATCH v4 43/52] docs: infrastructure.rst: don't include firmware kernel-doc Mauro Carvalho Chehab
2020-09-30 13:25 ` [PATCH v4 44/52] docs: gpu: i915.rst: Fix several C duplication warnings Mauro Carvalho Chehab
2020-09-30 13:25   ` [Intel-gfx] " Mauro Carvalho Chehab
2020-09-30 13:25   ` Mauro Carvalho Chehab
2020-09-30 13:25 ` [PATCH v4 45/52] docs: devices.rst: fix a C reference markup Mauro Carvalho Chehab
2020-09-30 13:25 ` [PATCH v4 46/52] docs: it_IT: hacking.rst: fix a typo on a markup Mauro Carvalho Chehab
2020-10-01 12:05   ` Federico Vaga
2020-09-30 13:25 ` [PATCH v4 47/52] docs: mei.rst: fix a C expression markup Mauro Carvalho Chehab
2020-09-30 20:30   ` Winkler, Tomas
2020-09-30 13:25 ` [PATCH v4 48/52] docs: basics.rst: avoid duplicated C function declaration Mauro Carvalho Chehab
2020-09-30 13:25 ` [PATCH v4 49/52] workqueue: fix a kernel-doc warning Mauro Carvalho Chehab
2020-09-30 15:57   ` Tejun Heo
2020-09-30 13:25 ` [PATCH v4 50/52] scripts: kernel-doc: try to use c:function if possible Mauro Carvalho Chehab
2020-09-30 13:25 ` [PATCH v4 51/52] docs: conf.py: fix c:function support with Sphinx 3.x Mauro Carvalho Chehab
2020-09-30 13:25 ` [PATCH v4 52/52] docs: conf.py: change the Sphinx 3.x+ text Mauro Carvalho Chehab
2020-10-01 21:48 ` [PATCH v4 00/52] Fix html build with Sphinx 3.1 and above Jonathan Corbet
2020-10-02  6:52   ` Mauro Carvalho Chehab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=689d790237b64fc7d81fcf97ac303cc1dbdd33d4.1601467849.git.mchehab+huawei@kernel.org \
    --to=mchehab+huawei@kernel.org \
    --cc=corbet@lwn.net \
    --cc=ebiggers@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.