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  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]
Date:   Sat, 30 Apr 2022 13:19:59 +0000
From:   Vladimir Oltean <>
To:     Sebastian Andrzej Siewior <>
CC:     Kurt Kanzenbach <>,
        "" <>,
        Jakub Kicinski <>,
        "David S. Miller" <>,
        Paolo Abeni <>,
        Eric Dumazet <>,
        Florian Fainelli <>,
        Vivien Didelot <>,
        Andrew Lunn <>,
        Claudiu Manoil <>,
        Alexandre Belloni <>,
        "" <>,
        Vinicius Costa Gomes <>,
        Gerhard Engleder <>,
        "Y.B. Lu" <>,
        Xiaoliang Yang <>,
        Richard Cochran <>,
        Yannick Vignon <>,
        Rui Sousa <>, Jiri Pirko <>,
        Ido Schimmel <>
Subject: Re: [PATCH net-next] selftests: forwarding: add Per-Stream Filtering
 and Policing test for Ocelot

Hi Sebastian,

On Fri, Apr 29, 2022 at 04:30:47PM +0200, Sebastian Andrzej Siewior wrote:
> On 2022-04-29 11:00:39 [+0000], Vladimir Oltean wrote:
> > > I agree. Nevertheless, having a standardized tool for this kind latency
> > > testing would be nice. For instance, cyclictest is also not part of the
> > > kernel, but packaged for all major Linux distributions.
> > 
> > Right, the thing is that I'm giving myself the liberty to still make
> > backwards-incompatible changes to isochron until it reaches v1.0 (right
> > now it's at v0.7 + 14 patches, so v0.8 should be coming rather soon).
> > I don't really want to submit unstable software for inclusion in a
> > distro (plus I don't know what distros would be interested in TSN
> > testing, see above).
> Users of those distros, that need to test TSN, will be interested in
> having it packaged rather than having it to compile first. Just make it
> available, point to it in tests etc. and it should get packaged.
> > And isochron itself needs to become more stable by gathering more users,
> > being integrated in scripts such as selftests, catering to more varied
> > requirements.
> > So it's a bit of a chicken and egg situation.
> If it is completely experimental then it could be added to, say,
> Debian's experimental distribution so user's of unstable/sid can install
> it fairly easy but it won't become part of the upcoming stable release
> (the relevant freeze is currently set to 2023-02).
> Sebastian

If I get you right, you're saying it would be preferable to submit
isochron for inclusion in Debian Testing.

Ok, I've submitted an Intent To Package:

but if you don't mind, I'd still like to proceed with v2 right away,
since the process of getting isochron packaged by Debian is essentially
unbounded and I wouldn't like to create a dependency between packaging
and this selftest. There is already a link to the Github repo in, I expect people are still going to get it from there for a
while. I will also make the dependency optional via a REQUIRE_ISOCHRON
variable, as discussed with Kurt. I hope that's ok.

Powered by blists - more mailing lists