netdev - Re: [PATCH net-next 0/1] Introduction of the tc tests

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170619224027.133c3578@plumbers-lap.home.lan>
Date:   Mon, 19 Jun 2017 22:40:27 -0700
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     David Miller <davem@...emloft.net>
Cc:     xiyou.wangcong@...il.com, lucasb@...atatu.com,
        netdev@...r.kernel.org, jiri@...nulli.us, mrv@...atatu.com,
        jhs@...atatu.com
Subject: Re: [PATCH net-next 0/1] Introduction of the tc tests

On Mon, 19 Jun 2017 23:48:19 -0400 (EDT)
David Miller <davem@...emloft.net> wrote:

> From: Cong Wang <xiyou.wangcong@...il.com>
> Date: Mon, 19 Jun 2017 16:37:29 -0700
> 
> > Hi,
> > 
> > On Fri, Jun 16, 2017 at 2:22 PM, Lucas Bates <lucasb@...atatu.com> wrote:  
> >> Apologies for sending this as one big patch. I've been sitting on this a little
> >> too long, but it's ready and I wanted to get it out.
> >>
> >> There are a limited number of tests to start - I plan to add more on a regular
> >> basis.
> >>
> >> Lucas Bates (1):
> >>   selftests: Introduce tc testsuite  
> > 
> > Nice work!
> > 
> > Is there any particular reason you want to put these tests in kernel tree
> > especially tools/testing/selftests/ ?  
> 
> Yeah, it would be absolutely terrible if we had more tests in the
> kernel selftests area for networking.
> 
> More seriously, we need more, not less, tests in the kernel networking
> selftests directory.
> 
> It doesn't belong in iproute2 because we want a place to put things
> that automatically get tested when someone makes kernel changes and
> can be integrated into the kernel development workflow.
> 
> I want as many tests as possible under there, so I'm really surprised
> that you're asking "why" tests are being added there.

The "Occum's razor" for deciding where tests belong should be does
the test need to change to respond to kernel change? Don't want to have
iproute2 tests that have if (kernel_version > ...)