lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <54C68E15.9060002@cumulusnetworks.com>
Date:	Mon, 26 Jan 2015 10:57:25 -0800
From:	roopa <roopa@...ulusnetworks.com>
To:	Scott Feldman <sfeldma@...il.com>
CC:	Netdev <netdev@...r.kernel.org>, shemminger@...tta.com,
	"vyasevic@...hat.com" <vyasevic@...hat.com>,
	Wilson Kok <wkok@...ulusnetworks.com>
Subject: Re: [PATCH net-next v3 2/2] iproute2: bridge vlan show new option
 to print ranges

On 1/25/15, 10:09 PM, roopa wrote:
> On 1/25/15, 9:57 PM, Scott Feldman wrote:
>> On Sun, Jan 25, 2015 at 9:18 PM, roopa <roopa@...ulusnetworks.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 ...  ;)
This still means i will end up changing the default/current output into 
vlan ranges on newer kernels. If that is acceptable then i will resubmit 
with v4.
If not, v3 looks ok to me so far.

thanks,
Roopa


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ