Re: [PATCH net-next v3 2/2] iproute2: bridge vlan show new option to print ranges

[roopa <roopa@cumulusnetworks.com>]

On 1/25/15, 9:57 PM, Scott Feldman wrote:
> On Sun, Jan 25, 2015 at 9:18 PM, roopa <roopa@cumulusnetworks.com> wrote:
>> On 1/25/15, 8:35 PM, Scott Feldman wrote:
>>>> diff --git a/bridge/bridge.c b/bridge/bridge.c
>>>> index 5fcc552..88469ca 100644
>>>> --- a/bridge/bridge.c
>>>> +++ b/bridge/bridge.c
>>>> @@ -21,6 +21,7 @@ int resolve_hosts;
>>>>    int oneline = 0;
>>>>    int show_stats;
>>>>    int show_details;
>>>> +int compress_vlans;
>>>>    int timestamp;
>>>>    char * _SL_ = NULL;
>>>>
>>>> @@ -32,7 +33,8 @@ static void usage(void)
>>>>    "Usage: bridge [ OPTIONS ] OBJECT { COMMAND | help }\n"
>>>>    "where  OBJECT := { link | fdb | mdb | vlan | monitor }\n"
>>>>    "       OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails] |\n"
>>>> -"                    -o[neline] | -t[imestamp] | -n[etns] name }\n");
>>>> +"                    -o[neline] | -t[imestamp] | -n[etns] name |\n"
>>>> +"                    -c[ompressvlans] }\n");
>>> This option is awkward at this level since it's specific to bridge vlan
>>> cmd.
>>>
>>> Is it even necessary?  The real user of compressed vlans isn't the
>>> "bridge show" cmd; just keep "bridge show" simple, listing each vlan
>>> per line.
>> without ranges it does get a bit difficult (or rather long) to read if there
>> are many vlans (it was also a comment I received on v2).
>>
>> All the available options whether they apply to the immediate sub-command or
>> not are at the toplevel command today.
>> Hence the position (Not a big fan of the current name. suggestions welcome).
>>
>> I would have loved to have the default output print ranges, If that is
>> acceptable. But, that can break new iproute2 on older kernels (If that is
>> something we should care about).
>>
>> other option is keyword argument like maybe 'bridge vlan show compressed' or
>> 'bridge vlan show ranges'
> How about try RTEXT_FILTER_BRVLAN_COMPRESSED first, and if that fails,
> try RTEXT_FILTER_BRVLAN, and don't add -c option?
>
>
That would have been nice, except that  it will not fail. It will pass 
but not return any vlans.

Better would be to send both flags. I think that will work. New kernel 
looks at RTEXT_FILTER_BRVLAN_COMPRESSED first.
v4  soon ....after some testing ...  ;)