mirror of
https://git.proxmox.com/git/mirror_frr
synced 2025-08-15 08:57:29 +00:00
Merge pull request #14499 from qlyoung/fix-doc-whitespace-toctree
fix various developer doc issues
This commit is contained in:
commit
f48f2de17c
@ -58,6 +58,7 @@ If config rollbacks are enabled using ``--enable-config-rollbacks``
|
|||||||
the sqlite3 developer package also should be installed.
|
the sqlite3 developer package also should be installed.
|
||||||
|
|
||||||
.. code-block:: console
|
.. code-block:: console
|
||||||
|
|
||||||
sudo apt install libsqlite3-dev
|
sudo apt install libsqlite3-dev
|
||||||
|
|
||||||
|
|
||||||
|
@ -1,5 +1,7 @@
|
|||||||
.. SPDX-License-Identifier: GPL-2.0-only
|
.. SPDX-License-Identifier: GPL-2.0-only
|
||||||
|
|
||||||
|
.. _checkpatch:
|
||||||
|
|
||||||
==========
|
==========
|
||||||
Checkpatch
|
Checkpatch
|
||||||
==========
|
==========
|
||||||
|
@ -639,13 +639,14 @@ in order into ``*argv[]``. Before this happens the ``->arg`` field is set to
|
|||||||
point at the snippet of user input that matched it.
|
point at the snippet of user input that matched it.
|
||||||
|
|
||||||
For most nontrivial commands the handler function will need to determine which
|
For most nontrivial commands the handler function will need to determine which
|
||||||
of the possible matching inputs was entered. Previously this was done by looking
|
of the possible matching inputs was entered. Previously this was done by
|
||||||
at the first few characters of input. This is now considered an anti-pattern and
|
looking at the first few characters of input. This is now considered an
|
||||||
should be avoided. Instead, the ``->type`` or ``->text`` fields for this logic.
|
anti-pattern and should be avoided. Instead, use the ``->type`` or ``->text``
|
||||||
The ``->type`` field can be used when the possible inputs differ in type. When
|
fields for this logic. The ``->type`` field can be used when the possible
|
||||||
the possible types are the same, use the ``->text`` field. This field has the
|
inputs differ in type. When the possible types are the same, use the ``->text``
|
||||||
full text of the corresponding token in the definition string and using it makes
|
field. This field has the full text of the corresponding token in the
|
||||||
for much more readable code. An example is helpful.
|
definition string and using it makes for much more readable code. An example is
|
||||||
|
helpful.
|
||||||
|
|
||||||
Command definition:
|
Command definition:
|
||||||
|
|
||||||
@ -654,9 +655,10 @@ Command definition:
|
|||||||
command <(1-10)|foo|BAR>
|
command <(1-10)|foo|BAR>
|
||||||
|
|
||||||
In this example, the user may enter any one of:
|
In this example, the user may enter any one of:
|
||||||
- an integer between 1 and 10
|
|
||||||
- "foo"
|
* an integer between 1 and 10
|
||||||
- anything at all
|
* "foo"
|
||||||
|
* anything at all
|
||||||
|
|
||||||
If the user enters "command f", then:
|
If the user enters "command f", then:
|
||||||
|
|
||||||
@ -793,12 +795,12 @@ Adding a CLI Node
|
|||||||
|
|
||||||
To add a new CLI node, you should:
|
To add a new CLI node, you should:
|
||||||
|
|
||||||
- define a new numerical node constant
|
#. define a new numerical node constant
|
||||||
- define a node structure in the relevant daemon
|
#. define a node structure in the relevant daemon
|
||||||
- call ``install_node()`` in the relevant daemon
|
#. call ``install_node()`` in the relevant daemon
|
||||||
- define and install the new node in vtysh
|
#. define and install the new node in vtysh
|
||||||
- define corresponding node entry commands in daemon and vtysh
|
#. define corresponding node entry commands in daemon and vtysh
|
||||||
- add a new entry to the ``ctx_keywords`` dictionary in ``tools/frr-reload.py``
|
#. add a new entry to the ``ctx_keywords`` dictionary in ``tools/frr-reload.py``
|
||||||
|
|
||||||
Defining the numerical node constant
|
Defining the numerical node constant
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
@ -24,7 +24,8 @@ to the cost of the cuurent path from the source up to the current node.
|
|||||||
|
|
||||||
The algorithm is as followed:
|
The algorithm is as followed:
|
||||||
|
|
||||||
```
|
.. code-block:: c
|
||||||
|
|
||||||
cost = MAX_COST;
|
cost = MAX_COST;
|
||||||
Priority_Queue.empty();
|
Priority_Queue.empty();
|
||||||
Visited_Node.empty();
|
Visited_Node.empty();
|
||||||
@ -76,7 +77,6 @@ The algorithm is as followed:
|
|||||||
return (next_path.destination == destination);
|
return (next_path.destination == destination);
|
||||||
}
|
}
|
||||||
|
|
||||||
```
|
|
||||||
|
|
||||||
Definition
|
Definition
|
||||||
----------
|
----------
|
||||||
|
@ -5,6 +5,7 @@ FRRouting Developer's Guide
|
|||||||
:maxdepth: 2
|
:maxdepth: 2
|
||||||
|
|
||||||
workflow
|
workflow
|
||||||
|
checkpatch
|
||||||
building
|
building
|
||||||
packaging
|
packaging
|
||||||
process-architecture
|
process-architecture
|
||||||
|
@ -9,4 +9,5 @@ OSPFD
|
|||||||
|
|
||||||
ospf-api
|
ospf-api
|
||||||
ospf-sr
|
ospf-sr
|
||||||
|
cspf
|
||||||
|
|
||||||
|
@ -472,8 +472,8 @@ For each capture a window is opened displaying a live summary of the captured
|
|||||||
packets. Additionally, the entire packet stream is captured in a pcap file in
|
packets. Additionally, the entire packet stream is captured in a pcap file in
|
||||||
the tests log directory e.g.,::
|
the tests log directory e.g.,::
|
||||||
|
|
||||||
When using a unified log file `frr.log` one substitutes `frr` for the daemon
|
When using a unified log file ``frr.log`` one substitutes ``frr`` for the
|
||||||
name in the ``--logd`` CLI option, e.g.,
|
daemon name in the ``--logd`` CLI option, e.g.,
|
||||||
|
|
||||||
.. code:: shell
|
.. code:: shell
|
||||||
|
|
||||||
@ -617,6 +617,8 @@ allocations upon exit. To enable also reporting of memory leaks to a specific
|
|||||||
location, define an environment variable ``TOPOTESTS_CHECK_MEMLEAK`` with the
|
location, define an environment variable ``TOPOTESTS_CHECK_MEMLEAK`` with the
|
||||||
file prefix, i.e.:
|
file prefix, i.e.:
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
export TOPOTESTS_CHECK_MEMLEAK="/home/mydir/memleak_"
|
export TOPOTESTS_CHECK_MEMLEAK="/home/mydir/memleak_"
|
||||||
|
|
||||||
For tests that support the TOPOTESTS_CHECK_MEMLEAK environment variable, this
|
For tests that support the TOPOTESTS_CHECK_MEMLEAK environment variable, this
|
||||||
|
@ -817,6 +817,7 @@ The project provides multiple tools to allow you to correctly style your code
|
|||||||
as painlessly as possible, primarily built around ``clang-format``.
|
as painlessly as possible, primarily built around ``clang-format``.
|
||||||
|
|
||||||
clang-format
|
clang-format
|
||||||
|
|
||||||
In the project root there is a :file:`.clang-format` configuration file
|
In the project root there is a :file:`.clang-format` configuration file
|
||||||
which can be used with the ``clang-format`` source formatter tool from the
|
which can be used with the ``clang-format`` source formatter tool from the
|
||||||
LLVM project. Most of the time, this is the easiest and smartest tool to
|
LLVM project. Most of the time, this is the easiest and smartest tool to
|
||||||
@ -875,6 +876,8 @@ clang-format
|
|||||||
checkpatch.sh
|
checkpatch.sh
|
||||||
checkpatch.pl
|
checkpatch.pl
|
||||||
|
|
||||||
|
.. seealso:: :ref:`checkpatch`
|
||||||
|
|
||||||
In the Linux kernel source tree there is a Perl script used to check
|
In the Linux kernel source tree there is a Perl script used to check
|
||||||
incoming patches for style errors. FRR uses a shell script front end and an
|
incoming patches for style errors. FRR uses a shell script front end and an
|
||||||
adapted version of the perl script for the same purpose. These scripts can
|
adapted version of the perl script for the same purpose. These scripts can
|
||||||
|
Loading…
Reference in New Issue
Block a user