netdev - Re: [PATCH iproute2 3/3] bridge: request vlans along with link information

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]

Date:   Sun, 10 Sep 2017 21:36:23 +0300
From:   Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To:     Roman Mashak <mrv@...atatu.com>
Cc:     Roopa Prabhu <roopa@...ulusnetworks.com>,
        "stephen@...workplumber.org" <stephen@...workplumber.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Jamal Hadi Salim <jhs@...atatu.com>
Subject: Re: [PATCH iproute2 3/3] bridge: request vlans along with link
 information

On 10/09/17 21:18, Roman Mashak wrote:
> Nikolay Aleksandrov <nikolay@...ulusnetworks.com> writes:
> 
>> On 10/09/17 16:38, Roman Mashak wrote:
> 
> [...]
> 
>>> Since VLAN info is already in link messages, there is no other option but
>>> dump it in monitor or "bridge link show". Yes, the output may be lengthy
>>
>> To make sure there's no misunderstanding - on GETLINK the vlan info is _not_
>> dumped by default (not compressed or otherwise).
> 
> Yes, I understand it, I was referring to link events in the previous
> comment. However, why not to report compressed vlans for GETLINK by
> default if show_details is true, this would be consistent with events monitor.
> 

So my point is to only print the compressed vlans when the -c flag is present on
both occasions. I don't have any strong feeling about this, my only concern is that
people using -d with monitor will start suddenly seeing a lot more than they expect.
The -c (which already exists) will give them the option to skip it. Also the getlink
with lots of vlans and ports will grow by default if there's no way to remove the
vlan dumps (be it compressed or not).

In general I'd prefer to have only one way to do things, e.g. in this particular
case I'd advise people to use bridge vlan show, but I get it that monitor doesn't
show them anywhere. Maybe all of this should go under bridge monitor vlan or
bridge -compressvlans monitor link. Anyway, if other people are fine with extending
the 'show_details' only, then I won't stay in the way.

> It seems to be more clear and intuitive from the user's perspective, the
> same set of command line options for \monitor' or 'show' commands.
> 

That I completely agree with. :-)

>> It is only dumped compressed on port notifications, that is why I suggested to
>> use the already present flag (-compressvlans, -c) in order to include that info
>> when monitoring or dumping link info, so people watching for the port flags
>> (show_details) would not suddenly start getting a lot more and it makes sense
>> to dump it only on specific request.
>>
>>> and hard to digest for a human, that is why I put it under "show_details"
>>> kludge - if one is requesting details, he/she should be prepared for
>>> large volumes of data to be shown :)
>>>
>>> As Nikolay suggested, it'll make sense to request compressed
>>> output by default, this will be addresses in v2 patch.
>>>
>>> [...]
>>>