Re: [PATCH net-next 0/4] netlink: fix ynl spec tooling robustness bugs
From: tmbates12
Date: Sat Sep 12 2026 - 13:35:48 EST
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?
> 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.
On Thu, Sep 10, 2026 at 10:23 PM Jakub Kicinski <kuba@xxxxxxxxxx> wrote:
>
> On Tue, 08 Sep 2026 19:45:06 -0400 Taylor Bates wrote:
> > This series is intended to address several robustness bugs found in the ynl
> > tooling and the netlink-raw YAML specification.
> >
> > These issues were found while writing a netlink-raw spec for the Bridge
> > VLAN family. However each stands independently of that work, and fixes
> > bugs in the parser that can be reproduced against the existing spec
> > definitions.
>
> 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.
>
> > The patches in this series carry Fixes tags, but are all in developer
> > tooling and have no effect on the running kernel. That is why they have
> > been targeted at net-next rather than net.
>
> 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 :/