Hello!

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.

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.

Signed-off-by: Taylor Bates <tmbates12@gmail.com>
---
Taylor Bates (4):
      netlink: specs: fix duplicate if/then keys in netlink-raw schema
      tools: ynl: reject zero-length attributes instead of looping forever
      tools: ynl: stop find_kernel_root() spinning at the filesystem root
      tools: ynl: fix uapi generation for anonymous enums with documented entries

 Documentation/netlink/netlink-raw.yaml | 31 +++++++++++++++++--------------
 tools/net/ynl/pyynl/lib/ynl.py         |  4 ++++
 tools/net/ynl/pyynl/ynl_gen_c.py       | 13 ++++++++++---
 3 files changed, 31 insertions(+), 17 deletions(-)
---
base-commit: ab217fbb9b2169ce677b09a66558d5c3adcfbb76
change-id: 20260907-ynl-robustness-d62d9693cc12

Best regards,
--  
Taylor Bates <tmbates12@gmail.com>

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 :/

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@kernel.org> 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 :/

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

On Mon, 14 Sep 2026 16:12:06 -0700 Jakub Kicinski wrote:
> 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).

Sorry, I was unclear on this, I have a feeling that I misread your
earlier point,
I didn't mean to sound like I was proposing any OVS work. Neither on the
the spec nor the kernel code gen. I do agree that 4/4 doesn't have any
necessity pinned to anything in-tree with that context in mind now.

I'll be sending out the repost for 1/1 shortly, and once I flesh out the rest of
the doc keys in the yaml.

I'd assume that starting the bridge spec out as an RFC would be appropriate
while we see how much work it'll take, but I'd just like to confirm beforehand.

On Mon, 14 Sep 2026 21:46:09 -0400 tmbates12 wrote:
> I'd assume that starting the bridge spec out as an RFC would be appropriate
> while we see how much work it'll take, but I'd just like to confirm beforehand.

RFC or PATCH doesn't really matter here. RFC sounds fine