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

[Jakub Kicinski]

On Sat, 12 Sep 2026 13:35:16 -0400 tmbates12 wrote:
> On Thu, 10 Sep 2026 22:23:14 -0700 Jakub Kicinski wrote:
> > 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.

> > 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).