On Thu, Oct 30, 2025 at 08:39:44AM -0700, Jakub Kicinski wrote:
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?
I just do `make install` in tools/net/ynl. Both the ynl scripts and specs are installed. So I think the specs are also tested.
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.
Yes
Maybe the solution is as simple as finding and alias'ing ynl to the cli.py ?
I didn't get here. The `ynl` calls pyynl.cli:main, that should be enough. Do you mean we should find the `cli.py` path and call it like `$source_code/tools/net/ynl/pyynl/cli.py --spec $source_code/Documentation/netlink/specs/xxx.yaml ...`?
Thanks Hangbin