[iproute2] bridge: make mcast_flood description consistent

This patch simply changes the description of the mcast_flood flag
with "flood" instead of "be flooded with" to avoid confusion, and be
consistent with the description of the flooding flag, which "Controls
whether a given port will *flood* unicast traffic for which there is
no FDB entry."

Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com>
---
 man/man8/bridge.8     | 2 +-
 man/man8/ip-link.8.in | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

On Tue, Feb 19, 2019 at 06:47:38PM -0500, Vivien Didelot wrote:
> This patch simply changes the description of the mcast_flood flag
> with "flood" instead of "be flooded with" to avoid confusion, and be
> consistent with the description of the flooding flag, which "Controls
> whether a given port will *flood* unicast traffic for which there is
> no FDB entry."

Hi Vivien,

I'm not sure if it's in the current iproute2, but there is a
discrepency between the arguments for 'bridge' stated in the man page
and the description thereof:

       bridge link set dev DEV  [ cost COST ] [ priority PRIO ] [ state STATE
...
               } ] [ learning_sync { on | off } ] [ flood { on | off } ] [
                                                    ^^^^^^^^^^^^^^^^^^

vs

       flooding on or flooding off
              Controls whether a given port will flood unicast traffic for
              which there is no FDB entry. By default this flag is on.

vs the command actually accepting "flood" not "flooding".  I spotted
that in iproute2-4.20.0.  I haven't had a chance to generate a patch
that yet and work out how to submit it, but thanks for leading the
way!

> 
> Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com>
> ---
>  man/man8/bridge.8     | 2 +-
>  man/man8/ip-link.8.in | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/man/man8/bridge.8 b/man/man8/bridge.8
> index 72210f62..03b33d34 100644
> --- a/man/man8/bridge.8
> +++ b/man/man8/bridge.8
> @@ -361,7 +361,7 @@ switch.
>  
>  .TP
>  .BR "mcast_flood on " or " mcast_flood off "
> -Controls whether a given port will be flooded with multicast traffic for which there is no MDB entry. By default this flag is on.
> +Controls whether a given port will flood multicast traffic for which there is no MDB entry. By default this flag is on.
>  
>  .TP
>  .BR "neigh_suppress on " or " neigh_suppress off "
> diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
> index 5132f514..cef489a4 100644
> --- a/man/man8/ip-link.8.in
> +++ b/man/man8/ip-link.8.in
> @@ -2155,7 +2155,7 @@ queries.
>  option above.
>  
>  .BR mcast_flood " { " on " | " off " }"
> -- controls whether a given port will be flooded with multicast traffic for which there is no MDB entry.
> +- controls whether a given port will flood multicast traffic for which there is no MDB entry.
>  
>  .BI group_fwd_mask " MASK "
>  - set the group forward mask. This is the bitmask that is applied to decide whether to forward incoming frames destined to link-local addresses, ie addresses of the form 01:80:C2:00:00:0X (defaults to 0, ie the bridge does not forward any link-local frames coming on this port).
> -- 
> 2.20.1
> 
>

Hi Russell,

On Wed, 20 Feb 2019 00:05:29 +0000, Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
> I'm not sure if it's in the current iproute2, but there is a
> discrepency between the arguments for 'bridge' stated in the man page
> and the description thereof:
> 
>        bridge link set dev DEV  [ cost COST ] [ priority PRIO ] [ state STATE
> ...
>                } ] [ learning_sync { on | off } ] [ flood { on | off } ] [
>                                                     ^^^^^^^^^^^^^^^^^^
> 
> vs
> 
>        flooding on or flooding off
>               Controls whether a given port will flood unicast traffic for
>               which there is no FDB entry. By default this flag is on.
> 
> vs the command actually accepting "flood" not "flooding".  I spotted
> that in iproute2-4.20.0.  I haven't had a chance to generate a patch
> that yet and work out how to submit it, but thanks for leading the
> way!

You are correct! I've sent a v2.


Thank you,

	Vivien