Re: [PATCH nft 1/4] doc: add documentation about list hooks feature

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Fri, Jul 26, 2024 at 03:58:28AM +0200, Florian Westphal wrote:
> Add a brief segment about 'nft list hooks' and a summary
> of the output format.
> 
> As nft.txt is quite large, split the additonal commands
> into their own file.
> 
> The existing listing section is removed; list subcommand is
> already mentioned in the relevant statement sections.
> 
> Reported-by: Phil Sutter <phil@nwl.cc>
> Signed-off-by: Florian Westphal <fw@strlen.de>
> ---
>  Makefile.am                 |   1 +
>  doc/additional-commands.txt | 115 ++++++++++++++++++++++++++++++++++++
>  doc/nft.txt                 |  63 +-------------------
>  3 files changed, 117 insertions(+), 62 deletions(-)
>  create mode 100644 doc/additional-commands.txt
> 
> diff --git a/Makefile.am b/Makefile.am
> index 9088170bfc68..ef198dafcbc8 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -322,6 +322,7 @@ A2X_OPTS_MANPAGE = \
>  ASCIIDOC_MAIN = doc/nft.txt
>  
>  ASCIIDOC_INCLUDES = \
> +	doc/additional-commands.txt \
>  	doc/data-types.txt \
>  	doc/payload-expression.txt \
>  	doc/primary-expression.txt \
> diff --git a/doc/additional-commands.txt b/doc/additional-commands.txt
> new file mode 100644
> index 000000000000..dd1b3d2d87d4
> --- /dev/null
> +++ b/doc/additional-commands.txt
> @@ -0,0 +1,115 @@
> +LIST HOOKS
> +~~~~~~~~~~
> +
> +This shows the low-level netfilter processing pipeline, including
> +functions registered by kernel modules such as nf_conntrack. +
> +
> +[verse]
> +____
> +*list hooks* ['family']
> +*list hooks netdev device* 'DEVICE_NAME'
> +____
> +
> +*list hooks* is enough to display everything that is active
> +on the system, however, it does currently omit hooks that are
> +tied to a specific network device (netdev family). To obtain
> +those, the network device needs to be queried by name.

IIRC, the idea is to display the ingress path pipeline according to
the device (if specified)

        list hooks netdev eth0

as for egress, as it is not possible to know where the packet is
going, it is probably good to allow the user to specify the output
device, so it gets the entire pipeline for ingress and egress
paths, ie.

list hooks netdev eth0 eth1

Note that this is not implemented. This has limitations, discovering
eth{0,1} belongs to bridge device would need more work (not asking to
do this now, but it could be a nice usability feature to discover the
pipeline?).