On 10/09/17 21:18, Roman Mashak wrote: > Nikolay Aleksandrov <niko...@cumulusnetworks.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. >>> >>> [...] >>>
