Re: [PATCH net-next 0/4] netlink: fix ynl spec tooling robustness bugs

On Sat, 12 Sep 2026 13:35:16 -0400 tmbates12 wrote:

On Thu, 10 Sep 2026 22:23:14 -0700 Jakub Kicinski wrote:

quoted

Why are you doing this? What's your intended use?
YNL extensions for classic families are unlikely to be accepted.
It's definitely not a goal for us to backfill all the ancient baggage.  

As part of work I've been doing on switchdev based ethernet switches
for configuration and state monitoring, I'd like to avoid having to rely
on shelling out to iproute2 to query bridge VLAN devices.
Parsing its output is fine as it can emit structured JSON
output, but as bridge(8) always resolves the ifindex to its interface
name, additional lookups are required in order to find the ifindex.

Is a bridge VLAN spec something you would consider at all, or should
I drop the idea before writing it up?

I see, so you have a real use for this.
Let's get patch 1 reposted and merged, and then send out the whole
thing, we can judge how much hacking it takes to support the bridge.

quoted

So you know that the Fixes tags are pointless and yet you add them?
Please, if it's not a bug that needs to go to LTS it should not have
a Fixes tag :/  

Understood, I will drop the Fixes: tags.

I will be dropping patches 2/4 and 3/4 based on your comments on each.
I'll drop 4/4 as well, since I'm not planning to submit the OVS spec
work it would need to go with.

Do you mean kernel side code gen for OVS? I thought we have specs for
most of OVS already, we just don't use them for kernel code gen (since
it's a pretty stable code base).