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:   Wed, 30 Sep 2020 23:11:26 +0300
From:   Vlad Buslov <vlad@...lov.dev>
To:     Stephen Hemminger <stephen@...workplumber.org>
Cc:     David Ahern <dsahern@...il.com>, Vlad Buslov <vladbu@...dia.com>,
        netdev@...r.kernel.org, Vlad Buslov <vladbu@...lanox.com>,
        Jiri Pirko <jiri@...lanox.com>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Cong Wang <xiyou.wangcong@...il.com>
Subject: Re: [RESEND PATCH iproute2-next 2/2] tc: implement support for terse dump

On Wed 30 Sep 2020 at 20:33, Stephen Hemminger <stephen@...workplumber.org> wrote:
> On Wed, 30 Sep 2020 08:57:20 -0700
> David Ahern <dsahern@...il.com> wrote:
>
>> On 9/30/20 12:36 AM, Vlad Buslov wrote:
>> > From: Vlad Buslov <vladbu@...lanox.com>
>> > 
>> > Implement support for classifier/action terse dump using new TCA_DUMP_FLAGS
>> > tlv with only available flag value TCA_DUMP_FLAGS_TERSE. Set the flag when
>> > user requested it with following example CLI:
>> >   
>> >> tc -s filter show terse dev ens1f0 ingress  
>> 
>> this should be consistent with ip command which has -br for 'brief'
>> output. so this should be
>> 
>>    tc -s -br filter show dev ens1f0 ingress
>> 
>> Other tc maintainers should weigh in on what data should be presented
>> for this mode.
>
> Current ip brief mode is good, one line per interface. Something similar with tc
> would be best.

Hi Stephen,

My proposed implementation is very simple because it relies on existing
infrastructure that omits printing data that is not included in the
netlink packet. Making terse/brief dump output one line per filter would
require extending every single classifier with either standalone
callback for such print or dedicated block in existing print_op().
Moreover, it would be complicated for me to decide what should be
included in such output for many classifiers that I don't have
experience using.

Do you think complicating implementation like that is worth it?

Regards,
Vlad

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ