[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251030083944.722833ac@kernel.org>
Date: Thu, 30 Oct 2025 08:39:44 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Hangbin Liu <liuhangbin@...il.com>
Cc: netdev@...r.kernel.org, Donald Hunter <donald.hunter@...il.com>, "David
S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo
Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, Jan Stancek
<jstancek@...hat.com>, "Matthieu Baerts (NGI0)" <matttbe@...nel.org>,
Asbjørn Sloth Tønnesen <ast@...erby.net>,
Stanislav Fomichev <sdf@...ichev.me>, Shuah Khan <shuah@...nel.org>, Ido
Schimmel <idosch@...dia.com>, Guillaume Nault <gnault@...hat.com>, Petr
Machata <petrm@...dia.com>, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net-next 3/3] selftests: net: add YNL test framework
On Thu, 30 Oct 2025 06:00:24 +0000 Hangbin Liu wrote:
> > Hm, my knee-jerk reaction was that we should avoid adding too much ynl
> > stuff to the kernel at this point. But looking closer it's not that
> > long.
> >
> > Do I understand correctly, tho, that you're testing _system_ YNL?
> > Not what's in tree?
>
> Kind of. With this we can test both the system's YNL and also make sure the
> YNL interface has no regression.
Meaning we still test the spec, right?
To state the obvious ideally we'd test both the specs and the Python
tools. Strictly better, and without it adding tests for new Python
features will be a little annoying for people running the selftest.
Maybe the solution is as simple as finding and alias'ing ynl to the
cli.py ?
Powered by blists - more mailing lists