All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Tobin C. Harding" <me@tobin.cc>
To: Daniel Borkmann <daniel@iogearbox.net>,
	Alexei Starovoitov <ast@kernel.org>
Cc: "Tobin C. Harding" <me@tobin.cc>,
	Jonathan Corbet <corbet@lwn.net>,
	"David S. Miller" <davem@davemloft.net>,
	linux-doc@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH bpf-next 11/13] docs: net: Use correct RST list construct
Date: Wed,  1 Aug 2018 15:09:06 +1000	[thread overview]
Message-ID: <20180801050908.29970-12-me@tobin.cc> (raw)
In-Reply-To: <20180801050908.29970-1-me@tobin.cc>

Currently we are using a custom list format.  We should use the correct
standard list construct.  Also lists require a newline before and after
the list items.

Use correct RST list construct.

Signed-off-by: Tobin C. Harding <me@tobin.cc>
---
 Documentation/networking/filter.rst | 30 ++++++++++++++++-------------
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/Documentation/networking/filter.rst b/Documentation/networking/filter.rst
index 1ed6972c3544..99dfa74fc4f7 100644
--- a/Documentation/networking/filter.rst
+++ b/Documentation/networking/filter.rst
@@ -1162,18 +1162,21 @@ arithmetic), and this is tracked in two parts: the 'fixed offset' and 'variable
 offset'.  The former is used when an exactly-known value (e.g. an immediate
 operand) is added to a pointer, while the latter is used for values which are
 not exactly known.  The variable offset is also used in SCALAR_VALUEs, to track
-the range of possible values in the register.
-The verifier's knowledge about the variable offset consists of:
+the range of possible values in the register.  The verifier's knowledge
+about the variable offset consists of:
+
 * minimum and maximum values as unsigned
 * minimum and maximum values as signed
 * knowledge of the values of individual bits, in the form of a 'tnum': a u64
-'mask' and a u64 'value'.  1s in the mask represent bits whose value is unknown;
-1s in the value represent bits known to be 1.  Bits known to be 0 have 0 in both
-mask and value; no bit should ever be 1 in both.  For example, if a byte is read
-into a register from memory, the register's top 56 bits are known zero, while
-the low 8 are unknown - which is represented as the tnum (0x0; 0xff).  If we
-then OR this with 0x40, we get (0x40; 0xbf), then if we add 1 we get (0x0;
-0x1ff), because of potential carries.
+  'mask' and a u64 'value'
+
+1s in the mask represent bits whose value is unknown; 1s in the value
+represent bits known to be 1.  Bits known to be 0 have 0 in both mask and
+value; no bit should ever be 1 in both.  For example, if a byte is read
+into a register from memory, the register's top 56 bits are known zero,
+while the low 8 are unknown - which is represented as the tnum (0x0; 0xff).
+If we then OR this with 0x40, we get (0x40; 0xbf), then if we add 1 we get
+(0x0; 0x1ff), because of potential carries.
 
 Besides arithmetic, the register state can also be updated by conditional
 branches.  For instance, if a SCALAR_VALUE is compared > 8, in the 'true' branch
@@ -1329,10 +1332,11 @@ are concurrently updating.
 maps can have different types: hash, array, bloom filter, radix-tree, etc.
 
 The map is defined by:
-  . type
-  . max number of elements
-  . key size in bytes
-  . value size in bytes
+
+- type
+- max number of elements
+- key size in bytes
+- value size in bytes
 
 Pruning
 =======
-- 
2.17.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: "Tobin C. Harding" <me@tobin.cc>
To: Daniel Borkmann <daniel@iogearbox.net>,
	Alexei Starovoitov <ast@kernel.org>
Cc: "Tobin C. Harding" <me@tobin.cc>,
	Jonathan Corbet <corbet@lwn.net>,
	"David S. Miller" <davem@davemloft.net>,
	linux-doc@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH bpf-next 11/13] docs: net: Use correct RST list construct
Date: Wed,  1 Aug 2018 15:09:06 +1000	[thread overview]
Message-ID: <20180801050908.29970-12-me@tobin.cc> (raw)
In-Reply-To: <20180801050908.29970-1-me@tobin.cc>

Currently we are using a custom list format.  We should use the correct
standard list construct.  Also lists require a newline before and after
the list items.

Use correct RST list construct.

Signed-off-by: Tobin C. Harding <me@tobin.cc>
---
 Documentation/networking/filter.rst | 30 ++++++++++++++++-------------
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/Documentation/networking/filter.rst b/Documentation/networking/filter.rst
index 1ed6972c3544..99dfa74fc4f7 100644
--- a/Documentation/networking/filter.rst
+++ b/Documentation/networking/filter.rst
@@ -1162,18 +1162,21 @@ arithmetic), and this is tracked in two parts: the 'fixed offset' and 'variable
 offset'.  The former is used when an exactly-known value (e.g. an immediate
 operand) is added to a pointer, while the latter is used for values which are
 not exactly known.  The variable offset is also used in SCALAR_VALUEs, to track
-the range of possible values in the register.
-The verifier's knowledge about the variable offset consists of:
+the range of possible values in the register.  The verifier's knowledge
+about the variable offset consists of:
+
 * minimum and maximum values as unsigned
 * minimum and maximum values as signed
 * knowledge of the values of individual bits, in the form of a 'tnum': a u64
-'mask' and a u64 'value'.  1s in the mask represent bits whose value is unknown;
-1s in the value represent bits known to be 1.  Bits known to be 0 have 0 in both
-mask and value; no bit should ever be 1 in both.  For example, if a byte is read
-into a register from memory, the register's top 56 bits are known zero, while
-the low 8 are unknown - which is represented as the tnum (0x0; 0xff).  If we
-then OR this with 0x40, we get (0x40; 0xbf), then if we add 1 we get (0x0;
-0x1ff), because of potential carries.
+  'mask' and a u64 'value'
+
+1s in the mask represent bits whose value is unknown; 1s in the value
+represent bits known to be 1.  Bits known to be 0 have 0 in both mask and
+value; no bit should ever be 1 in both.  For example, if a byte is read
+into a register from memory, the register's top 56 bits are known zero,
+while the low 8 are unknown - which is represented as the tnum (0x0; 0xff).
+If we then OR this with 0x40, we get (0x40; 0xbf), then if we add 1 we get
+(0x0; 0x1ff), because of potential carries.
 
 Besides arithmetic, the register state can also be updated by conditional
 branches.  For instance, if a SCALAR_VALUE is compared > 8, in the 'true' branch
@@ -1329,10 +1332,11 @@ are concurrently updating.
 maps can have different types: hash, array, bloom filter, radix-tree, etc.
 
 The map is defined by:
-  . type
-  . max number of elements
-  . key size in bytes
-  . value size in bytes
+
+- type
+- max number of elements
+- key size in bytes
+- value size in bytes
 
 Pruning
 =======
-- 
2.17.1


  parent reply	other threads:[~2018-08-01  5:12 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-01  5:08 [PATCH bpf-next 00/13] docs: Convert BPF filter.txt to RST Tobin C. Harding
2018-08-01  5:08 ` Tobin C. Harding
2018-08-01  5:08 ` [PATCH bpf-next 01/13] docs: net: Rename filter.txt to filter.rst Tobin C. Harding
2018-08-01  5:08   ` Tobin C. Harding
2018-08-01  5:08 ` [PATCH bpf-next 02/13] docs: Update references " Tobin C. Harding
2018-08-01  5:08   ` Tobin C. Harding
2018-08-01  5:08 ` [PATCH bpf-next 03/13] docs: net: Add filter to index toctree Tobin C. Harding
2018-08-01  5:08   ` Tobin C. Harding
2018-08-01 13:52   ` Jonathan Corbet
2018-08-01 13:52     ` Jonathan Corbet
2018-08-01 22:32     ` Tobin C. Harding
2018-08-01 22:32       ` Tobin C. Harding
2018-08-01  5:08 ` [PATCH bpf-next 04/13] docs: net: Use correct heading adornments Tobin C. Harding
2018-08-01  5:08   ` Tobin C. Harding
2018-08-01  5:09 ` [PATCH bpf-next 05/13] docs: net: Fix indentation issues for code snippets Tobin C. Harding
2018-08-01  5:09   ` Tobin C. Harding
2018-08-03  8:44   ` Daniel Borkmann
2018-08-03  8:44     ` Daniel Borkmann
2018-08-06  0:22     ` Tobin C. Harding
2018-08-06  0:22       ` Tobin C. Harding
2018-08-01  5:09 ` [PATCH bpf-next 06/13] docs: net: Remove non-standard identifiers Tobin C. Harding
2018-08-01  5:09   ` Tobin C. Harding
2018-08-01  5:09 ` [PATCH bpf-next 07/13] docs: net: Use double ticks instead of single quote Tobin C. Harding
2018-08-01  5:09   ` Tobin C. Harding
2018-08-01  5:09 ` [PATCH bpf-next 08/13] docs: net: Use double ticks instead of single tick Tobin C. Harding
2018-08-01  5:09   ` Tobin C. Harding
2018-08-01  5:09 ` [PATCH bpf-next 09/13] docs: net: Use lowercase 'k' for kernel Tobin C. Harding
2018-08-01  5:09   ` Tobin C. Harding
2018-08-01  5:09 ` [PATCH bpf-next 10/13] docs: net: Embed reference to seccomp_filter Tobin C. Harding
2018-08-01  5:09   ` Tobin C. Harding
2018-08-01  5:09 ` Tobin C. Harding [this message]
2018-08-01  5:09   ` [PATCH bpf-next 11/13] docs: net: Use correct RST list construct Tobin C. Harding
2018-08-01  5:09 ` [PATCH bpf-next 12/13] docs: net: Fix various minor typos Tobin C. Harding
2018-08-01  5:09   ` Tobin C. Harding
2018-08-03  8:41   ` Daniel Borkmann
2018-08-03  8:41     ` Daniel Borkmann
2018-08-06  0:23     ` Tobin C. Harding
2018-08-06  0:23       ` Tobin C. Harding
2018-08-08  1:42     ` Tobin C. Harding
2018-08-08  1:42       ` Tobin C. Harding
2018-08-08 13:23       ` Jonathan Corbet
2018-08-08 13:23         ` Jonathan Corbet
2018-08-08 13:45         ` Daniel Borkmann
2018-08-08 13:45           ` Daniel Borkmann
2018-08-08 16:26           ` Markus Heiser
2018-08-08 16:26             ` Markus Heiser
2018-08-08 22:21             ` Tobin C. Harding
2018-08-08 22:21               ` Tobin C. Harding
2018-08-01  5:09 ` [PATCH bpf-next 13/13] docs: net: Fix authors list to render as a list Tobin C. Harding
2018-08-01  5:09   ` Tobin C. Harding

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=20180801050908.29970-12-me@tobin.cc \
    --to=me@tobin.cc \
    --cc=ast@kernel.org \
    --cc=corbet@lwn.net \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /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.