All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Phil Sutter <phil@nwl.cc>, netfilter-devel@vger.kernel.org
Subject: Re: RFC: nft.8 review
Date: Tue, 20 Dec 2016 00:53:30 +0100	[thread overview]
Message-ID: <20161219235330.GA7565@salvia> (raw)
In-Reply-To: <20161210102715.GA2955@orbyte.nwl.cc>

Hi Phil,

On Sat, Dec 10, 2016 at 11:27:16AM +0100, Phil Sutter wrote:
> Hi,
> 
> I skimmed through nft man page and noted down problems I discovered.
> While doing so, I got the idea to restructure the whole document for
> better organization and comprehensibility but wanted to hear your
> thoughts first before creating a ticket in netfilter BZ:
> 
> 
> * Use BNF in synopses
> 
> This is rudimentally used in the SYNOPSIS section already, but just
> lists _cmd_ without explanation - although the fun is only about to
> start at this point. :)
> 
> What I really don't like is the syntax used in e.g. CHAINS section: it
> is not only imprecise (nothing says you have to use 'priority <prio>'
> but may not use 'table <table>', but also plain wrong when it comes to
> the mandatory braces around the chain_block.

Right, that needs a fix.

> * Organize entity descriptions BNF-style
> 
> In my opinion the order of (sub-)sections is a bit chaotic at times.
> E.g. RULES section synopsis tries to explain how a rule is made up from
> statements, but these are not explained before five sections later (not
> counting the bogus BLA section ;).
> 
> The idea here is to go from most generic to most specific, like things
> are defined in yacc - just not as explicit, since if I want to know the
> relation between concat_rhs_expr and shift_rhs_expr, I can just as well
> read the code itself.
>
> * What about sub-pages?
> 
> Looking at some expressions' descriptions, it seems like these might
> grow exponentially with the documentation improving. So maybe it makes
> sense to follow iptables' advice and have 'nft-extensions.8'? I would
> have called it 'nft-statements.8' or 'nft-expressions.8' but the two are
> too much intertwined to keep them separate.
> 
> OK, maybe this can wait until nft.8 really has become awfully long.

Yes, let's wait a bit for the split.

> Comments, flame, donations highly appreciated, of course!

Patches are very welcome!

  reply	other threads:[~2016-12-19 23:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-10 10:27 RFC: nft.8 review Phil Sutter
2016-12-19 23:53 ` Pablo Neira Ayuso [this message]
2016-12-20 16:27   ` mark diener
2016-12-20 17:21     ` Phil Sutter
2016-12-20 17:42       ` mark diener

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=20161219235330.GA7565@salvia \
    --to=pablo@netfilter.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=phil@nwl.cc \
    /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.