[PATCH net-next 00/13] tools: ynl: c: basic netlink-raw support

[PATCH net-next 00/13] tools: ynl: c: basic netlink-raw support

[Jakub Kicinski]

Basic support for netlink-raw AKA classic netlink in user space C codegen.
This series is enough to read routes and addresses from the kernel
(see the samples in patches 12 and 13).

Specs need to be slightly adjusted and decorated with the c naming info.

In terms of codegen this series includes just the basic plumbing required
to skip genlmsghdr and handle request types which may technically also
be legal in genetlink-legacy but are very uncommon there.

Subsequent series will add support for:
 - handling CRUD-style notifications
 - code gen for array types classic netlink uses
 - sub-message support

Jakub Kicinski (13):
  netlink: specs: rename rtnetlink specs in accordance with family name
  netlink: specs: rt-route: specify fixed-header at operations level
  netlink: specs: rt-addr: remove the fixed members from attrs
  netlink: specs: rt-route: remove the fixed members from attrs
  netlink: specs: rt-addr: add C naming info
  netlink: specs: rt-route: add C naming info
  tools: ynl: support creating non-genl sockets
  tools: ynl-gen: don't consider requests with fixed hdr empty
  tools: ynl: don't use genlmsghdr in classic netlink
  tools: ynl-gen: consider dump ops without a do "type-consistent"
  tools: ynl-gen: use family c-name in notifications
  tools: ynl: generate code for rt-addr and add a sample
  tools: ynl: generate code for rt-route and add a sample

 .../specs/{rt_addr.yaml => rt-addr.yaml}      | 24 ++----
 .../specs/{rt_link.yaml => rt-link.yaml}      |  0
 .../specs/{rt_neigh.yaml => rt-neigh.yaml}    |  0
 .../specs/{rt_route.yaml => rt-route.yaml}    | 22 ++---
 .../specs/{rt_rule.yaml => rt-rule.yaml}      |  0
 .../userspace-api/netlink/netlink-raw.rst     |  2 +-
 tools/net/ynl/Makefile.deps                   |  2 +
 tools/net/ynl/generated/Makefile              |  2 +-
 tools/net/ynl/lib/ynl-priv.h                  |  3 +
 tools/net/ynl/lib/ynl.h                       |  3 +
 tools/net/ynl/lib/ynl.c                       | 59 +++++++++-----
 tools/net/ynl/samples/rt-addr.c               | 80 +++++++++++++++++++
 tools/net/ynl/samples/rt-route.c              | 80 +++++++++++++++++++
 tools/net/ynl/pyynl/ynl_gen_c.py              | 55 +++++++++----
 tools/net/ynl/samples/.gitignore              |  4 +-
 tools/testing/selftests/net/lib/py/ynl.py     |  4 +-
 16 files changed, 263 insertions(+), 77 deletions(-)
 rename Documentation/netlink/specs/{rt_addr.yaml => rt-addr.yaml} (89%)
 rename Documentation/netlink/specs/{rt_link.yaml => rt-link.yaml} (100%)
 rename Documentation/netlink/specs/{rt_neigh.yaml => rt-neigh.yaml} (100%)
 rename Documentation/netlink/specs/{rt_route.yaml => rt-route.yaml} (93%)
 rename Documentation/netlink/specs/{rt_rule.yaml => rt-rule.yaml} (100%)
 create mode 100644 tools/net/ynl/samples/rt-addr.c
 create mode 100644 tools/net/ynl/samples/rt-route.c

-- 
2.49.0

[PATCH net-next 01/13] netlink: specs: rename rtnetlink specs in accordance with family name

[Jakub Kicinski]

The rtnetlink family names are set to rt-$name within the YAML
but the files are called rt_$name. C codegen assumes that the
generated file name will match the family. We could replace
dashes with underscores in the codegen but making sure the
family name matches the spec name may be more generally useful.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
 Documentation/netlink/specs/{rt_addr.yaml => rt-addr.yaml}   | 0
 Documentation/netlink/specs/{rt_link.yaml => rt-link.yaml}   | 0
 Documentation/netlink/specs/{rt_neigh.yaml => rt-neigh.yaml} | 0
 Documentation/netlink/specs/{rt_route.yaml => rt-route.yaml} | 0
 Documentation/netlink/specs/{rt_rule.yaml => rt-rule.yaml}   | 0
 Documentation/userspace-api/netlink/netlink-raw.rst          | 2 +-
 tools/testing/selftests/net/lib/py/ynl.py                    | 4 ++--
 7 files changed, 3 insertions(+), 3 deletions(-)
 rename Documentation/netlink/specs/{rt_addr.yaml => rt-addr.yaml} (100%)
 rename Documentation/netlink/specs/{rt_link.yaml => rt-link.yaml} (100%)
 rename Documentation/netlink/specs/{rt_neigh.yaml => rt-neigh.yaml} (100%)
 rename Documentation/netlink/specs/{rt_route.yaml => rt-route.yaml} (100%)
 rename Documentation/netlink/specs/{rt_rule.yaml => rt-rule.yaml} (100%)

diff --git a/Documentation/netlink/specs/rt_addr.yaml b/Documentation/netlink/specs/rt-addr.yaml
similarity index 100%
rename from Documentation/netlink/specs/rt_addr.yaml
rename to Documentation/netlink/specs/rt-addr.yaml
diff --git a/Documentation/netlink/specs/rt_link.yaml b/Documentation/netlink/specs/rt-link.yaml
similarity index 100%
rename from Documentation/netlink/specs/rt_link.yaml
rename to Documentation/netlink/specs/rt-link.yaml
diff --git a/Documentation/netlink/specs/rt_neigh.yaml b/Documentation/netlink/specs/rt-neigh.yaml
similarity index 100%
rename from Documentation/netlink/specs/rt_neigh.yaml
rename to Documentation/netlink/specs/rt-neigh.yaml
diff --git a/Documentation/netlink/specs/rt_route.yaml b/Documentation/netlink/specs/rt-route.yaml
similarity index 100%
rename from Documentation/netlink/specs/rt_route.yaml
rename to Documentation/netlink/specs/rt-route.yaml
diff --git a/Documentation/netlink/specs/rt_rule.yaml b/Documentation/netlink/specs/rt-rule.yaml
similarity index 100%
rename from Documentation/netlink/specs/rt_rule.yaml
rename to Documentation/netlink/specs/rt-rule.yaml
diff --git a/Documentation/userspace-api/netlink/netlink-raw.rst b/Documentation/userspace-api/netlink/netlink-raw.rst
index 1990eea772d0..31fc91020eb3 100644
--- a/Documentation/userspace-api/netlink/netlink-raw.rst
+++ b/Documentation/userspace-api/netlink/netlink-raw.rst
@@ -62,7 +62,7 @@ Sub-messages
 ------------
 
 Several raw netlink families such as
-:doc:`rt_link<../../networking/netlink_spec/rt_link>` and
+:doc:`rt-link<../../networking/netlink_spec/rt-link>` and
 :doc:`tc<../../networking/netlink_spec/tc>` use attribute nesting as an
 abstraction to carry module specific information.
 
diff --git a/tools/testing/selftests/net/lib/py/ynl.py b/tools/testing/selftests/net/lib/py/ynl.py
index 8986c584cb37..6329ae805abf 100644
--- a/tools/testing/selftests/net/lib/py/ynl.py
+++ b/tools/testing/selftests/net/lib/py/ynl.py
@@ -39,12 +39,12 @@ from .ksft import ksft_pr, ktap_result
 
 class RtnlFamily(YnlFamily):
     def __init__(self, recv_size=0):
-        super().__init__((SPEC_PATH / Path('rt_link.yaml')).as_posix(),
+        super().__init__((SPEC_PATH / Path('rt-link.yaml')).as_posix(),
                          schema='', recv_size=recv_size)
 
 class RtnlAddrFamily(YnlFamily):
     def __init__(self, recv_size=0):
-        super().__init__((SPEC_PATH / Path('rt_addr.yaml')).as_posix(),
+        super().__init__((SPEC_PATH / Path('rt-addr.yaml')).as_posix(),
                          schema='', recv_size=recv_size)
 
 class NetdevFamily(YnlFamily):
-- 
2.49.0

Re: [PATCH net-next 01/13] netlink: specs: rename rtnetlink specs in accordance with family name

[Jacob Keller]

On 4/8/2025 5:03 PM, Jakub Kicinski wrote:
> The rtnetlink family names are set to rt-$name within the YAML
> but the files are called rt_$name. C codegen assumes that the
> generated file name will match the family. We could replace
> dashes with underscores in the codegen but making sure the
> family name matches the spec name may be more generally useful.
> 
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
+1 to being more useful to have the family name match the spec name, I
agree.

Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>

Re: [PATCH net-next 01/13] netlink: specs: rename rtnetlink specs in accordance with family name

[Donald Hunter]

Jacob Keller <jacob.e.keller@intel.com> writes:

> On 4/8/2025 5:03 PM, Jakub Kicinski wrote:
>> The rtnetlink family names are set to rt-$name within the YAML
>> but the files are called rt_$name. C codegen assumes that the
>> generated file name will match the family. We could replace
>> dashes with underscores in the codegen but making sure the
>> family name matches the spec name may be more generally useful.
>> 
>> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
>> ---
> +1 to being more useful to have the family name match the spec name, I
> agree.
>
> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>

Agree that it's preferable that they match, and that `ynl --family ...`
searches by filename so they really ought to match.

I'll just note that the genl convention is underscores in family names,
if you wanted consistency across all families.

Reviewed-by: Donald Hunter <donald.hunter@gmail.com>

Re: [PATCH net-next 01/13] netlink: specs: rename rtnetlink specs in accordance with family name

[Jakub Kicinski]

I thought about it some more.

On Wed, 09 Apr 2025 13:15:42 +0100 Donald Hunter wrote:
> I'll just note that the genl convention is underscores in family names,
> if you wanted consistency across all families.

I wasn't clear on whether it's a convention or just how we did things
historically. We recommend the use of dashes in the spec itself so it
stands to reason to also use dashes in the family name.
But replacing dashes with underscores is a "C thing", and family name
string is used by all languages, so we shouldn't s/-/_/ when we output
the family name for the kernel's code struct genl_family.

IOW I think that either we 
- accept the slight inconsistency with old families using _, or 
- accept the slight annoyance with all languages having to do s/-/_/
  when looking up family ID, or 
- accept the inconsistency with all name properties in new YAML spec
  being separated with - and just the family name always using _.

:( I picked the first option, assuming the genl family names don't have
much of a convention. Admittedly I don't know of any with dashes but
some of them use capital letters :S

LMK if you think we should pick differently. In my mind picking option
1 is prioritizing consistency of the spec language over the consistency
of user experience. We can alleviate the annoyance of typing --family ..
with bash completions?

Re: [PATCH net-next 01/13] netlink: specs: rename rtnetlink specs in accordance with family name

[Donald Hunter]

On Wed, 9 Apr 2025 at 15:15, Jakub Kicinski <kuba@kernel.org> wrote:
>
> IOW I think that either we
> - accept the slight inconsistency with old families using _, or
> - accept the slight annoyance with all languages having to do s/-/_/
>   when looking up family ID, or
> - accept the inconsistency with all name properties in new YAML spec
>   being separated with - and just the family name always using _.
>
> :( I picked the first option, assuming the genl family names don't have
> much of a convention. Admittedly I don't know of any with dashes but
> some of them use capital letters :S
>
> LMK if you think we should pick differently. In my mind picking option
> 1 is prioritizing consistency of the spec language over the consistency
> of user experience. We can alleviate the annoyance of typing --family ..
> with bash completions?

That seems fair to me. FWIW, dashes seem more CLI friendly too. And
you make a good point that existing genl names really are all over the
place.

Donald.

[PATCH net-next 02/13] netlink: specs: rt-route: specify fixed-header at operations level

[Jakub Kicinski]

The C codegen currently stores the fixed-header as part of family
info, so it only supports one fixed-header type per spec. Luckily
all rtm route message have the same fixed header so just move it up
to the higher level.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
 Documentation/netlink/specs/rt-route.yaml | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/Documentation/netlink/specs/rt-route.yaml b/Documentation/netlink/specs/rt-route.yaml
index 292469c7d4b9..6fa3fa24305e 100644
--- a/Documentation/netlink/specs/rt-route.yaml
+++ b/Documentation/netlink/specs/rt-route.yaml
@@ -245,12 +245,12 @@ protonum: 0
 
 operations:
   enum-model: directional
+  fixed-header: rtmsg
   list:
     -
       name: getroute
       doc: Dump route information.
       attribute-set: route-attrs
-      fixed-header: rtmsg
       do:
         request:
           value: 26
@@ -320,7 +320,6 @@ protonum: 0
       name: newroute
       doc: Create a new route
       attribute-set: route-attrs
-      fixed-header: rtmsg
       do:
         request:
           value: 24
@@ -329,7 +328,6 @@ protonum: 0
       name: delroute
       doc: Delete an existing route
       attribute-set: route-attrs
-      fixed-header: rtmsg
       do:
         request:
           value: 25
-- 
2.49.0

Re: [PATCH net-next 02/13] netlink: specs: rt-route: specify fixed-header at operations level

[Jacob Keller]

On 4/8/2025 5:03 PM, Jakub Kicinski wrote:
> The C codegen currently stores the fixed-header as part of family
> info, so it only supports one fixed-header type per spec. Luckily
> all rtm route message have the same fixed header so just move it up
> to the higher level.
> 
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
>  Documentation/netlink/specs/rt-route.yaml | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/Documentation/netlink/specs/rt-route.yaml b/Documentation/netlink/specs/rt-route.yaml
> index 292469c7d4b9..6fa3fa24305e 100644
> --- a/Documentation/netlink/specs/rt-route.yaml
> +++ b/Documentation/netlink/specs/rt-route.yaml
> @@ -245,12 +245,12 @@ protonum: 0
>  
>  operations:
>    enum-model: directional
> +  fixed-header: rtmsg
>    list:
>      -
>        name: getroute
>        doc: Dump route information.
>        attribute-set: route-attrs
> -      fixed-header: rtmsg
>        do:
>          request:
>            value: 26

Nice. This seems simpler.

Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>

Re: [PATCH net-next 02/13] netlink: specs: rt-route: specify fixed-header at operations level

[Donald Hunter]

Jakub Kicinski <kuba@kernel.org> writes:

> The C codegen currently stores the fixed-header as part of family
> info, so it only supports one fixed-header type per spec. Luckily
> all rtm route message have the same fixed header so just move it up
> to the higher level.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
>  Documentation/netlink/specs/rt-route.yaml | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/Documentation/netlink/specs/rt-route.yaml b/Documentation/netlink/specs/rt-route.yaml
> index 292469c7d4b9..6fa3fa24305e 100644
> --- a/Documentation/netlink/specs/rt-route.yaml
> +++ b/Documentation/netlink/specs/rt-route.yaml
> @@ -245,12 +245,12 @@ protonum: 0
>  
>  operations:
>    enum-model: directional
> +  fixed-header: rtmsg

It's a cleaner spec this way too :)

Reviewed-by: Donald Hunter <donald.hunter@gmail.com>

[PATCH net-next 03/13] netlink: specs: rt-addr: remove the fixed members from attrs

[Jakub Kicinski]

The purpose of the attribute list is to list the attributes
which will be included in a given message to shrink the objects
for families with huge attr spaces. Fixed structs are always
present in their entirety so there's no point in listing
their members. Current C codegen doesn't expect them and
tries to look up the names in the attribute space.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
 Documentation/netlink/specs/rt-addr.yaml | 20 +++-----------------
 1 file changed, 3 insertions(+), 17 deletions(-)

diff --git a/Documentation/netlink/specs/rt-addr.yaml b/Documentation/netlink/specs/rt-addr.yaml
index df6b23f06a22..0488ce87506c 100644
--- a/Documentation/netlink/specs/rt-addr.yaml
+++ b/Documentation/netlink/specs/rt-addr.yaml
@@ -133,11 +133,6 @@ protonum: 0
         request:
           value: 20
           attributes: &ifaddr-all
-            - ifa-family
-            - ifa-flags
-            - ifa-prefixlen
-            - ifa-scope
-            - ifa-index
             - address
             - label
             - local
@@ -150,11 +145,6 @@ protonum: 0
         request:
           value: 21
           attributes:
-            - ifa-family
-            - ifa-flags
-            - ifa-prefixlen
-            - ifa-scope
-            - ifa-index
             - address
             - local
     -
@@ -164,8 +154,7 @@ protonum: 0
       dump:
         request:
           value: 22
-          attributes:
-            - ifa-index
+          attributes: []
         reply:
           value: 20
           attributes: *ifaddr-all
@@ -177,9 +166,7 @@ protonum: 0
       do:
         request:
           value: 58
-          attributes:
-            - ifa-family
-            - ifa-index
+          attributes: []
         reply:
           value: 58
           attributes: &mcaddr-attrs
@@ -188,8 +175,7 @@ protonum: 0
       dump:
         request:
           value: 58
-          attributes:
-            - ifa-family
+          attributes: []
         reply:
           value: 58
           attributes: *mcaddr-attrs
-- 
2.49.0

Re: [PATCH net-next 03/13] netlink: specs: rt-addr: remove the fixed members from attrs

[Jacob Keller]

On 4/8/2025 5:03 PM, Jakub Kicinski wrote:
> The purpose of the attribute list is to list the attributes
> which will be included in a given message to shrink the objects
> for families with huge attr spaces. Fixed structs are always
> present in their entirety so there's no point in listing
> their members. Current C codegen doesn't expect them and
> tries to look up the names in the attribute space.
> 
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
>  Documentation/netlink/specs/rt-addr.yaml | 20 +++-----------------
>  1 file changed, 3 insertions(+), 17 deletions(-)
> 
> diff --git a/Documentation/netlink/specs/rt-addr.yaml b/Documentation/netlink/specs/rt-addr.yaml
> index df6b23f06a22..0488ce87506c 100644
> --- a/Documentation/netlink/specs/rt-addr.yaml
> +++ b/Documentation/netlink/specs/rt-addr.yaml
> @@ -133,11 +133,6 @@ protonum: 0
>          request:
>            value: 20
>            attributes: &ifaddr-all
> -            - ifa-family
> -            - ifa-flags
> -            - ifa-prefixlen
> -            - ifa-scope
> -            - ifa-index

From the wording of the commit message, I interpreted it that if the
attribute list contains a struct, then its members are implicit and
don't have to be listed..?

I guess I'm missing something here since It doesn't seem like that is
the case.

Does the commit mean that structs are always available regardless of
whats listed in the attributes?

Re: [PATCH net-next 03/13] netlink: specs: rt-addr: remove the fixed members from attrs

[Jacob Keller]

On 4/8/2025 9:53 PM, Jacob Keller wrote:
> 
> 
> On 4/8/2025 5:03 PM, Jakub Kicinski wrote:
>> The purpose of the attribute list is to list the attributes
>> which will be included in a given message to shrink the objects
>> for families with huge attr spaces. Fixed structs are always
>> present in their entirety so there's no point in listing
>> their members. Current C codegen doesn't expect them and
>> tries to look up the names in the attribute space.
>>
>> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
>> ---
>>  Documentation/netlink/specs/rt-addr.yaml | 20 +++-----------------
>>  1 file changed, 3 insertions(+), 17 deletions(-)
>>
>> diff --git a/Documentation/netlink/specs/rt-addr.yaml b/Documentation/netlink/specs/rt-addr.yaml
>> index df6b23f06a22..0488ce87506c 100644
>> --- a/Documentation/netlink/specs/rt-addr.yaml
>> +++ b/Documentation/netlink/specs/rt-addr.yaml
>> @@ -133,11 +133,6 @@ protonum: 0
>>          request:
>>            value: 20
>>            attributes: &ifaddr-all
>> -            - ifa-family
>> -            - ifa-flags
>> -            - ifa-prefixlen
>> -            - ifa-scope
>> -            - ifa-index
> 
> From the wording of the commit message, I interpreted it that if the
> attribute list contains a struct, then its members are implicit and
> don't have to be listed..?
> 
> I guess I'm missing something here since It doesn't seem like that is
> the case.
> 
> Does the commit mean that structs are always available regardless of
> whats listed in the attributes?
> 

Ah. These messages have a fixed header which has its members defined,
and thats why we don't need to repeat them in the attribute list. Only
the struct that defines the header is used here. Ok.

Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>

Re: [PATCH net-next 03/13] netlink: specs: rt-addr: remove the fixed members from attrs

[Donald Hunter]

Jakub Kicinski <kuba@kernel.org> writes:

> The purpose of the attribute list is to list the attributes
> which will be included in a given message to shrink the objects
> for families with huge attr spaces. Fixed structs are always
> present in their entirety so there's no point in listing
> their members. Current C codegen doesn't expect them and
> tries to look up the names in the attribute space.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
>  Documentation/netlink/specs/rt-addr.yaml | 20 +++-----------------
>  1 file changed, 3 insertions(+), 17 deletions(-)
>
> diff --git a/Documentation/netlink/specs/rt-addr.yaml b/Documentation/netlink/specs/rt-addr.yaml
> index df6b23f06a22..0488ce87506c 100644
> --- a/Documentation/netlink/specs/rt-addr.yaml
> +++ b/Documentation/netlink/specs/rt-addr.yaml
> @@ -133,11 +133,6 @@ protonum: 0
>          request:
>            value: 20
>            attributes: &ifaddr-all
> -            - ifa-family
> -            - ifa-flags
> -            - ifa-prefixlen
> -            - ifa-scope
> -            - ifa-index
>              - address
>              - label
>              - local

Yeah, that's a consequence of me not really grokking the intended
purpose of listing message attrs when I wrote the spec.

Reviewed-by: Donald Hunter <donald.hunter@gmail.com>

[PATCH net-next 04/13] netlink: specs: rt-route: remove the fixed members from attrs

[Jakub Kicinski]

The purpose of the attribute list is to list the attributes
which will be included in a given message to shrink the objects
for families with huge attr spaces. Fixed structs are always
present in their entirety so there's no point in listing
their members. Current C codegen doesn't expect them and
tries to look up the names in the attribute space.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
 Documentation/netlink/specs/rt-route.yaml | 15 +--------------
 1 file changed, 1 insertion(+), 14 deletions(-)

diff --git a/Documentation/netlink/specs/rt-route.yaml b/Documentation/netlink/specs/rt-route.yaml
index 6fa3fa24305e..c7c6f776ab2f 100644
--- a/Documentation/netlink/specs/rt-route.yaml
+++ b/Documentation/netlink/specs/rt-route.yaml
@@ -255,11 +255,8 @@ protonum: 0
         request:
           value: 26
           attributes:
-            - rtm-family
             - src
-            - rtm-src-len
             - dst
-            - rtm-dst-len
             - iif
             - oif
             - ip-proto
@@ -271,15 +268,6 @@ protonum: 0
         reply:
           value: 24
           attributes: &all-route-attrs
-            - rtm-family
-            - rtm-dst-len
-            - rtm-src-len
-            - rtm-tos
-            - rtm-table
-            - rtm-protocol
-            - rtm-scope
-            - rtm-type
-            - rtm-flags
             - dst
             - src
             - iif
@@ -311,8 +299,7 @@ protonum: 0
       dump:
         request:
           value: 26
-          attributes:
-            - rtm-family
+          attributes: []
         reply:
           value: 24
           attributes: *all-route-attrs
-- 
2.49.0

Re: [PATCH net-next 04/13] netlink: specs: rt-route: remove the fixed members from attrs

[Jacob Keller]

On 4/8/2025 5:03 PM, Jakub Kicinski wrote:
> The purpose of the attribute list is to list the attributes
> which will be included in a given message to shrink the objects
> for families with huge attr spaces. Fixed structs are always
> present in their entirety so there's no point in listing
> their members. Current C codegen doesn't expect them and
> tries to look up the names in the attribute space.
> 
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>

Re: [PATCH net-next 04/13] netlink: specs: rt-route: remove the fixed members from attrs

[Donald Hunter]

Jakub Kicinski <kuba@kernel.org> writes:

> The purpose of the attribute list is to list the attributes
> which will be included in a given message to shrink the objects
> for families with huge attr spaces. Fixed structs are always
> present in their entirety so there's no point in listing
> their members. Current C codegen doesn't expect them and
> tries to look up the names in the attribute space.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Reviewed-by: Donald Hunter <donald.hunter@gmail.com>

[PATCH net-next 05/13] netlink: specs: rt-addr: add C naming info

[Jakub Kicinski]

Add properties needed for C codegen to match names with uAPI headers.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
 Documentation/netlink/specs/rt-addr.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/netlink/specs/rt-addr.yaml b/Documentation/netlink/specs/rt-addr.yaml
index 0488ce87506c..4f86aa1075da 100644
--- a/Documentation/netlink/specs/rt-addr.yaml
+++ b/Documentation/netlink/specs/rt-addr.yaml
@@ -2,6 +2,7 @@
 
 name: rt-addr
 protocol: netlink-raw
+uapi-header: linux/rtnetlink.h
 protonum: 0
 
 doc:
@@ -49,6 +50,8 @@ protonum: 0
   -
     name: ifa-flags
     type: flags
+    name-prefix: ifa-f-
+    enum-name:
     entries:
       -
         name: secondary
@@ -124,6 +127,7 @@ protonum: 0
 operations:
   fixed-header: ifaddrmsg
   enum-model: directional
+  name-prefix: rtm-
   list:
     -
       name: newaddr
-- 
2.49.0

Re: [PATCH net-next 05/13] netlink: specs: rt-addr: add C naming info

[Jacob Keller]

On 4/8/2025 5:03 PM, Jakub Kicinski wrote:
> Add properties needed for C codegen to match names with uAPI headers.
> 
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---

Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>

Re: [PATCH net-next 05/13] netlink: specs: rt-addr: add C naming info

[Donald Hunter]

Jakub Kicinski <kuba@kernel.org> writes:

> Add properties needed for C codegen to match names with uAPI headers.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Reviewed-by: Donald Hunter <donald.hunter@gmail.com>

[PATCH net-next 06/13] netlink: specs: rt-route: add C naming info

[Jakub Kicinski]

Add properties needed for C codegen to match names with uAPI headers.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
 Documentation/netlink/specs/rt-route.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/netlink/specs/rt-route.yaml b/Documentation/netlink/specs/rt-route.yaml
index c7c6f776ab2f..800f3a823d47 100644
--- a/Documentation/netlink/specs/rt-route.yaml
+++ b/Documentation/netlink/specs/rt-route.yaml
@@ -2,6 +2,7 @@
 
 name: rt-route
 protocol: netlink-raw
+uapi-header: linux/rtnetlink.h
 protonum: 0
 
 doc:
@@ -11,6 +12,7 @@ protonum: 0
   -
     name: rtm-type
     name-prefix: rtn-
+    enum-name:
     type: enum
     entries:
       - unspec
@@ -246,6 +248,7 @@ protonum: 0
 operations:
   enum-model: directional
   fixed-header: rtmsg
+  name-prefix: rtm-
   list:
     -
       name: getroute
-- 
2.49.0

Re: [PATCH net-next 06/13] netlink: specs: rt-route: add C naming info

[Jacob Keller]

On 4/8/2025 5:03 PM, Jakub Kicinski wrote:
> Add properties needed for C codegen to match names with uAPI headers.
> 
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>

Re: [PATCH net-next 06/13] netlink: specs: rt-route: add C naming info

[Donald Hunter]

Jakub Kicinski <kuba@kernel.org> writes:

> Add properties needed for C codegen to match names with uAPI headers.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Reviewed-by: Donald Hunter <donald.hunter@gmail.com>

[PATCH net-next 07/13] tools: ynl: support creating non-genl sockets

[Jakub Kicinski]

Classic netlink has static family IDs specified in YAML,
there is no family name -> ID lookup. Support providing
the ID info to the library via the generated struct and
make library use it. Since NETLINK_ROUTE is ID 0 we need
an extra boolean to indicate classic_id is to be used.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
 tools/net/ynl/lib/ynl.h          |  3 ++
 tools/net/ynl/lib/ynl.c          | 51 +++++++++++++++++++++-----------
 tools/net/ynl/pyynl/ynl_gen_c.py |  9 ++++--
 3 files changed, 43 insertions(+), 20 deletions(-)

diff --git a/tools/net/ynl/lib/ynl.h b/tools/net/ynl/lib/ynl.h
index 6cd570b283ea..59256e258130 100644
--- a/tools/net/ynl/lib/ynl.h
+++ b/tools/net/ynl/lib/ynl.h
@@ -2,6 +2,7 @@
 #ifndef __YNL_C_H
 #define __YNL_C_H 1
 
+#include <stdbool.h>
 #include <stddef.h>
 #include <linux/genetlink.h>
 #include <linux/types.h>
@@ -48,6 +49,8 @@ struct ynl_family {
 /* private: */
 	const char *name;
 	size_t hdr_len;
+	bool is_classic;
+	__u16 classic_id;
 	const struct ynl_ntf_info *ntf_info;
 	unsigned int ntf_info_size;
 };
diff --git a/tools/net/ynl/lib/ynl.c b/tools/net/ynl/lib/ynl.c
index ce32cb35007d..b9fda1a99453 100644
--- a/tools/net/ynl/lib/ynl.c
+++ b/tools/net/ynl/lib/ynl.c
@@ -663,6 +663,7 @@ ynl_sock_create(const struct ynl_family *yf, struct ynl_error *yse)
 	struct sockaddr_nl addr;
 	struct ynl_sock *ys;
 	socklen_t addrlen;
+	int sock_type;
 	int one = 1;
 
 	ys = malloc(sizeof(*ys) + 2 * YNL_SOCKET_BUFFER_SIZE);
@@ -675,7 +676,9 @@ ynl_sock_create(const struct ynl_family *yf, struct ynl_error *yse)
 	ys->rx_buf = &ys->raw_buf[YNL_SOCKET_BUFFER_SIZE];
 	ys->ntf_last_next = &ys->ntf_first;
 
-	ys->socket = socket(AF_NETLINK, SOCK_RAW, NETLINK_GENERIC);
+	sock_type = yf->is_classic ? yf->classic_id : NETLINK_GENERIC;
+
+	ys->socket = socket(AF_NETLINK, SOCK_RAW, sock_type);
 	if (ys->socket < 0) {
 		__perr(yse, "failed to create a netlink socket");
 		goto err_free_sock;
@@ -708,8 +711,9 @@ ynl_sock_create(const struct ynl_family *yf, struct ynl_error *yse)
 	ys->portid = addr.nl_pid;
 	ys->seq = random();
 
-
-	if (ynl_sock_read_family(ys, yf->name)) {
+	if (yf->is_classic) {
+		ys->family_id = yf->classic_id;
+	} else if (ynl_sock_read_family(ys, yf->name)) {
 		if (yse)
 			memcpy(yse, &ys->err, sizeof(*yse));
 		goto err_close_sock;
@@ -791,13 +795,21 @@ static int ynl_ntf_parse(struct ynl_sock *ys, const struct nlmsghdr *nlh)
 	struct ynl_parse_arg yarg = { .ys = ys, };
 	const struct ynl_ntf_info *info;
 	struct ynl_ntf_base_type *rsp;
-	struct genlmsghdr *gehdr;
+	__u32 cmd;
 	int ret;
 
-	gehdr = ynl_nlmsg_data(nlh);
-	if (gehdr->cmd >= ys->family->ntf_info_size)
+	if (ys->family->is_classic) {
+		cmd = nlh->nlmsg_type;
+	} else {
+		struct genlmsghdr *gehdr;
+
+		gehdr = ynl_nlmsg_data(nlh);
+		cmd = gehdr->cmd;
+	}
+
+	if (cmd >= ys->family->ntf_info_size)
 		return YNL_PARSE_CB_ERROR;
-	info = &ys->family->ntf_info[gehdr->cmd];
+	info = &ys->family->ntf_info[cmd];
 	if (!info->cb)
 		return YNL_PARSE_CB_ERROR;
 
@@ -811,7 +823,7 @@ static int ynl_ntf_parse(struct ynl_sock *ys, const struct nlmsghdr *nlh)
 		goto err_free;
 
 	rsp->family = nlh->nlmsg_type;
-	rsp->cmd = gehdr->cmd;
+	rsp->cmd = cmd;
 
 	*ys->ntf_last_next = rsp;
 	ys->ntf_last_next = &rsp->next;
@@ -863,18 +875,23 @@ int ynl_error_parse(struct ynl_parse_arg *yarg, const char *msg)
 static int
 ynl_check_alien(struct ynl_sock *ys, const struct nlmsghdr *nlh, __u32 rsp_cmd)
 {
-	struct genlmsghdr *gehdr;
+	if (ys->family->is_classic) {
+		if (nlh->nlmsg_type != rsp_cmd)
+			return ynl_ntf_parse(ys, nlh);
+	} else {
+		struct genlmsghdr *gehdr;
 
-	if (ynl_nlmsg_data_len(nlh) < sizeof(*gehdr)) {
-		yerr(ys, YNL_ERROR_INV_RESP,
-		     "Kernel responded with truncated message");
-		return -1;
+		if (ynl_nlmsg_data_len(nlh) < sizeof(*gehdr)) {
+			yerr(ys, YNL_ERROR_INV_RESP,
+			     "Kernel responded with truncated message");
+			return -1;
+		}
+
+		gehdr = ynl_nlmsg_data(nlh);
+		if (gehdr->cmd != rsp_cmd)
+			return ynl_ntf_parse(ys, nlh);
 	}
 
-	gehdr = ynl_nlmsg_data(nlh);
-	if (gehdr->cmd != rsp_cmd)
-		return ynl_ntf_parse(ys, nlh);
-
 	return 0;
 }
 
diff --git a/tools/net/ynl/pyynl/ynl_gen_c.py b/tools/net/ynl/pyynl/ynl_gen_c.py
index a1427c537030..9e00aac4801c 100755
--- a/tools/net/ynl/pyynl/ynl_gen_c.py
+++ b/tools/net/ynl/pyynl/ynl_gen_c.py
@@ -971,9 +971,6 @@ from lib import SpecFamily, SpecAttrSet, SpecAttr, SpecOperation, SpecEnumSet, S
     def resolve(self):
         self.resolve_up(super())
 
-        if self.yaml.get('protocol', 'genetlink') not in {'genetlink', 'genetlink-c', 'genetlink-legacy'}:
-            raise Exception("Codegen only supported for genetlink")
-
         self.c_name = c_lower(self.ident_name)
         if 'name-prefix' in self.yaml['operations']:
             self.op_prefix = c_upper(self.yaml['operations']['name-prefix'])
@@ -1020,6 +1017,9 @@ from lib import SpecFamily, SpecAttrSet, SpecAttr, SpecOperation, SpecEnumSet, S
     def new_operation(self, elem, req_value, rsp_value):
         return Operation(self, elem, req_value, rsp_value)
 
+    def is_classic(self):
+        return self.proto == 'netlink-raw'
+
     def _mark_notify(self):
         for op in self.msgs.values():
             if 'notify' in op:
@@ -2730,6 +2730,9 @@ _C_KW = {
 
     cw.block_start(f'{symbol} = ')
     cw.p(f'.name\t\t= "{family.c_name}",')
+    if family.is_classic():
+        cw.p(f'.is_classic\t= true,')
+        cw.p(f'.classic_id\t= {family.get("protonum")},')
     if family.fixed_header:
         cw.p(f'.hdr_len\t= sizeof(struct genlmsghdr) + sizeof(struct {c_lower(family.fixed_header)}),')
     else:
-- 
2.49.0

Re: [PATCH net-next 07/13] tools: ynl: support creating non-genl sockets

[Jacob Keller]

On 4/8/2025 5:03 PM, Jakub Kicinski wrote:
> Classic netlink has static family IDs specified in YAML,
> there is no family name -> ID lookup. Support providing
> the ID info to the library via the generated struct and
> make library use it. Since NETLINK_ROUTE is ID 0 we need
> an extra boolean to indicate classic_id is to be used.
> 
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>

Re: [PATCH net-next 07/13] tools: ynl: support creating non-genl sockets

[Donald Hunter]

Jakub Kicinski <kuba@kernel.org> writes:

> Classic netlink has static family IDs specified in YAML,
> there is no family name -> ID lookup. Support providing
> the ID info to the library via the generated struct and
> make library use it. Since NETLINK_ROUTE is ID 0 we need
> an extra boolean to indicate classic_id is to be used.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Reviewed-by: Donald Hunter <donald.hunter@gmail.com>

[PATCH net-next 08/13] tools: ynl-gen: don't consider requests with fixed hdr empty

[Jakub Kicinski]

C codegen skips generating the structs if request/reply has no attrs.
In such cases the request op takes no argument and return int
(rather than response struct). In case of classic netlink a lot of
information gets passed using the fixed struct, however, so adjust
the logic to consider a request empty only if it has no attrs _and_
no fixed struct.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
 tools/net/ynl/pyynl/ynl_gen_c.py | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/tools/net/ynl/pyynl/ynl_gen_c.py b/tools/net/ynl/pyynl/ynl_gen_c.py
index 9e00aac4801c..04f1ac62cb01 100755
--- a/tools/net/ynl/pyynl/ynl_gen_c.py
+++ b/tools/net/ynl/pyynl/ynl_gen_c.py
@@ -1247,6 +1247,9 @@ from lib import SpecFamily, SpecAttrSet, SpecAttr, SpecOperation, SpecEnumSet, S
         if op_mode == 'event':
             self.struct['reply'] = Struct(family, self.attr_set, type_list=op['event']['attributes'])
 
+    def type_empty(self, key):
+        return len(self.struct[key].attr_list) == 0 and self.fixed_hdr is None
+
 
 class CodeWriter:
     def __init__(self, nlib, out_file=None, overwrite=True):
@@ -2034,7 +2037,7 @@ _C_KW = {
 
 
 def print_req_type_helpers(ri):
-    if len(ri.struct["request"].attr_list) == 0:
+    if ri.type_empty("request"):
         return
     print_alloc_wrapper(ri, "request")
     print_type_helpers(ri, "request")
@@ -2057,7 +2060,7 @@ _C_KW = {
 
 
 def print_req_type(ri):
-    if len(ri.struct["request"].attr_list) == 0:
+    if ri.type_empty("request"):
         return
     print_type(ri, "request")
 
-- 
2.49.0

Re: [PATCH net-next 08/13] tools: ynl-gen: don't consider requests with fixed hdr empty

[Jacob Keller]

On 4/8/2025 5:03 PM, Jakub Kicinski wrote:
> C codegen skips generating the structs if request/reply has no attrs.
> In such cases the request op takes no argument and return int
> (rather than response struct). In case of classic netlink a lot of
> information gets passed using the fixed struct, however, so adjust
> the logic to consider a request empty only if it has no attrs _and_
> no fixed struct.
> 
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
>  tools/net/ynl/pyynl/ynl_gen_c.py | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/net/ynl/pyynl/ynl_gen_c.py b/tools/net/ynl/pyynl/ynl_gen_c.py
> index 9e00aac4801c..04f1ac62cb01 100755
> --- a/tools/net/ynl/pyynl/ynl_gen_c.py
> +++ b/tools/net/ynl/pyynl/ynl_gen_c.py
> @@ -1247,6 +1247,9 @@ from lib import SpecFamily, SpecAttrSet, SpecAttr, SpecOperation, SpecEnumSet, S
>          if op_mode == 'event':
>              self.struct['reply'] = Struct(family, self.attr_set, type_list=op['event']['attributes'])
>  
> +    def type_empty(self, key):
> +        return len(self.struct[key].attr_list) == 0 and self.fixed_hdr is None
> +
>  
Ahh.. I think I see where my mistake from earlier regarding the
attributes. classic netlink has a fixed struct + sometimes attributes.
We don't need to list struct members as part of attributes because the
header will always be there. Ok.

Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>

[PATCH net-next 09/13] tools: ynl: don't use genlmsghdr in classic netlink

[Jakub Kicinski]

Make sure the codegen calls the right YNL lib helper to start
the request based on family type. Classic netlink request must
not include the genl header.

Conversely don't expect genl headers in the responses.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
 tools/net/ynl/lib/ynl-priv.h     |  3 +++
 tools/net/ynl/lib/ynl.c          |  8 ++++----
 tools/net/ynl/pyynl/ynl_gen_c.py | 19 +++++++++++++++----
 3 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/tools/net/ynl/lib/ynl-priv.h b/tools/net/ynl/lib/ynl-priv.h
index 3c09a7bbfba5..634eb16548b9 100644
--- a/tools/net/ynl/lib/ynl-priv.h
+++ b/tools/net/ynl/lib/ynl-priv.h
@@ -94,6 +94,9 @@ struct ynl_ntf_base_type {
 	unsigned char data[] __attribute__((aligned(8)));
 };
 
+struct nlmsghdr *ynl_msg_start_req(struct ynl_sock *ys, __u32 id);
+struct nlmsghdr *ynl_msg_start_dump(struct ynl_sock *ys, __u32 id);
+
 struct nlmsghdr *
 ynl_gemsg_start_req(struct ynl_sock *ys, __u32 id, __u8 cmd, __u8 version);
 struct nlmsghdr *
diff --git a/tools/net/ynl/lib/ynl.c b/tools/net/ynl/lib/ynl.c
index b9fda1a99453..70f899a54007 100644
--- a/tools/net/ynl/lib/ynl.c
+++ b/tools/net/ynl/lib/ynl.c
@@ -451,14 +451,14 @@ ynl_gemsg_start(struct ynl_sock *ys, __u32 id, __u16 flags,
 	return nlh;
 }
 
-void ynl_msg_start_req(struct ynl_sock *ys, __u32 id)
+struct nlmsghdr *ynl_msg_start_req(struct ynl_sock *ys, __u32 id)
 {
-	ynl_msg_start(ys, id, NLM_F_REQUEST | NLM_F_ACK);
+	return ynl_msg_start(ys, id, NLM_F_REQUEST | NLM_F_ACK);
 }
 
-void ynl_msg_start_dump(struct ynl_sock *ys, __u32 id)
+struct nlmsghdr *ynl_msg_start_dump(struct ynl_sock *ys, __u32 id)
 {
-	ynl_msg_start(ys, id, NLM_F_REQUEST | NLM_F_ACK | NLM_F_DUMP);
+	return ynl_msg_start(ys, id, NLM_F_REQUEST | NLM_F_ACK | NLM_F_DUMP);
 }
 
 struct nlmsghdr *
diff --git a/tools/net/ynl/pyynl/ynl_gen_c.py b/tools/net/ynl/pyynl/ynl_gen_c.py
index 04f1ac62cb01..b0b47a493a86 100755
--- a/tools/net/ynl/pyynl/ynl_gen_c.py
+++ b/tools/net/ynl/pyynl/ynl_gen_c.py
@@ -1710,7 +1710,10 @@ _C_KW = {
         ri.cw.p(f'dst->{arg} = {arg};')
 
     if ri.fixed_hdr:
-        ri.cw.p('hdr = ynl_nlmsg_data_offset(nlh, sizeof(struct genlmsghdr));')
+        if ri.family.is_classic():
+            ri.cw.p('hdr = ynl_nlmsg_data(nlh);')
+        else:
+            ri.cw.p('hdr = ynl_nlmsg_data_offset(nlh, sizeof(struct genlmsghdr));')
         ri.cw.p(f"memcpy(&dst->_hdr, hdr, sizeof({ri.fixed_hdr}));")
     for anest in sorted(all_multi):
         aspec = struct[anest]
@@ -1857,7 +1860,10 @@ _C_KW = {
     ri.cw.block_start()
     ri.cw.write_func_lvar(local_vars)
 
-    ri.cw.p(f"nlh = ynl_gemsg_start_req(ys, {ri.nl.get_family_id()}, {ri.op.enum_name}, 1);")
+    if ri.family.is_classic():
+        ri.cw.p(f"nlh = ynl_msg_start_req(ys, {ri.op.enum_name});")
+    else:
+        ri.cw.p(f"nlh = ynl_gemsg_start_req(ys, {ri.nl.get_family_id()}, {ri.op.enum_name}, 1);")
 
     ri.cw.p(f"ys->req_policy = &{ri.struct['request'].render_name}_nest;")
     if 'reply' in ri.op[ri.op_mode]:
@@ -1926,7 +1932,10 @@ _C_KW = {
     else:
         ri.cw.p(f'yds.rsp_cmd = {ri.op.rsp_value};')
     ri.cw.nl()
-    ri.cw.p(f"nlh = ynl_gemsg_start_dump(ys, {ri.nl.get_family_id()}, {ri.op.enum_name}, 1);")
+    if ri.family.is_classic():
+        ri.cw.p(f"nlh = ynl_msg_start_dump(ys, {ri.op.enum_name});")
+    else:
+        ri.cw.p(f"nlh = ynl_gemsg_start_dump(ys, {ri.nl.get_family_id()}, {ri.op.enum_name}, 1);")
 
     if ri.fixed_hdr:
         ri.cw.p("hdr_len = sizeof(req->_hdr);")
@@ -2736,7 +2745,9 @@ _C_KW = {
     if family.is_classic():
         cw.p(f'.is_classic\t= true,')
         cw.p(f'.classic_id\t= {family.get("protonum")},')
-    if family.fixed_header:
+    if family.is_classic():
+        cw.p(f'.hdr_len\t= sizeof(struct {c_lower(family.fixed_header)}),')
+    elif family.fixed_header:
         cw.p(f'.hdr_len\t= sizeof(struct genlmsghdr) + sizeof(struct {c_lower(family.fixed_header)}),')
     else:
         cw.p('.hdr_len\t= sizeof(struct genlmsghdr),')
-- 
2.49.0

Re: [PATCH net-next 09/13] tools: ynl: don't use genlmsghdr in classic netlink

[Jacob Keller]

On 4/8/2025 5:03 PM, Jakub Kicinski wrote:
> Make sure the codegen calls the right YNL lib helper to start
> the request based on family type. Classic netlink request must
> not include the genl header.
> 
> Conversely don't expect genl headers in the responses.
> 
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>

Re: [PATCH net-next 09/13] tools: ynl: don't use genlmsghdr in classic netlink

[Donald Hunter]

Jakub Kicinski <kuba@kernel.org> writes:

> Make sure the codegen calls the right YNL lib helper to start
> the request based on family type. Classic netlink request must
> not include the genl header.
>
> Conversely don't expect genl headers in the responses.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Reviewed-by: Donald Hunter <donald.hunter@gmail.com>

[PATCH net-next 10/13] tools: ynl-gen: consider dump ops without a do "type-consistent"

[Jakub Kicinski]

If the type for the response to do and dump are the same we don't
generate it twice. This is called "type_consistent" in the generator.
Consider operations which only have dump to also be consistent.
This removes unnecessary "_dump" from the names. There's a number
of GET ops in classic Netlink which only have dump handlers.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
 tools/net/ynl/pyynl/ynl_gen_c.py | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/tools/net/ynl/pyynl/ynl_gen_c.py b/tools/net/ynl/pyynl/ynl_gen_c.py
index b0b47a493a86..c97cda43a604 100755
--- a/tools/net/ynl/pyynl/ynl_gen_c.py
+++ b/tools/net/ynl/pyynl/ynl_gen_c.py
@@ -1212,6 +1212,7 @@ from lib import SpecFamily, SpecAttrSet, SpecAttr, SpecOperation, SpecEnumSet, S
 
         # 'do' and 'dump' response parsing is identical
         self.type_consistent = True
+        self.type_onside = False
         if op_mode != 'do' and 'dump' in op:
             if 'do' in op:
                 if ('reply' in op['do']) != ('reply' in op["dump"]):
@@ -1219,7 +1220,8 @@ from lib import SpecFamily, SpecAttrSet, SpecAttr, SpecOperation, SpecEnumSet, S
                 elif 'reply' in op['do'] and op["do"]["reply"] != op["dump"]["reply"]:
                     self.type_consistent = False
             else:
-                self.type_consistent = False
+                self.type_consistent = True
+                self.type_onside = True
 
         self.attr_set = attr_set
         if not self.attr_set:
@@ -1516,7 +1518,9 @@ _C_KW = {
         suffix += f"{direction_to_suffix[direction]}"
     else:
         if direction == 'request':
-            suffix += '_req_dump'
+            suffix += '_req'
+            if not ri.type_onside:
+                suffix += '_dump'
         else:
             if ri.type_consistent:
                 if deref:
@@ -1995,7 +1999,7 @@ _C_KW = {
     if not direction and ri.type_name_conflict:
         suffix += '_'
 
-    if ri.op_mode == 'dump':
+    if ri.op_mode == 'dump' and not ri.type_onside:
         suffix += '_dump'
 
     ri.cw.block_start(line=f"struct {ri.family.c_name}{suffix}")
@@ -2979,7 +2983,7 @@ _C_KW = {
                     ri = RenderInfo(cw, parsed, args.mode, op, 'dump')
                     print_req_type(ri)
                     print_req_type_helpers(ri)
-                    if not ri.type_consistent:
+                    if not ri.type_consistent or ri.type_onside:
                         print_rsp_type(ri)
                     print_wrapped_type(ri)
                     print_dump_prototype(ri)
@@ -3057,7 +3061,7 @@ _C_KW = {
                 if 'dump' in op:
                     cw.p(f"/* {op.enum_name} - dump */")
                     ri = RenderInfo(cw, parsed, args.mode, op, "dump")
-                    if not ri.type_consistent:
+                    if not ri.type_consistent or ri.type_onside:
                         parse_rsp_msg(ri, deref=True)
                     print_req_free(ri)
                     print_dump_type_free(ri)
-- 
2.49.0

Re: [PATCH net-next 10/13] tools: ynl-gen: consider dump ops without a do "type-consistent"

[Jacob Keller]

On 4/8/2025 5:03 PM, Jakub Kicinski wrote:
> If the type for the response to do and dump are the same we don't
> generate it twice. This is called "type_consistent" in the generator.
> Consider operations which only have dump to also be consistent.
> This removes unnecessary "_dump" from the names. There's a number
> of GET ops in classic Netlink which only have dump handlers.
> 
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
Makes sense.

Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>

Re: [PATCH net-next 10/13] tools: ynl-gen: consider dump ops without a do "type-consistent"

[Donald Hunter]

Jakub Kicinski <kuba@kernel.org> writes:

> If the type for the response to do and dump are the same we don't
> generate it twice. This is called "type_consistent" in the generator.
> Consider operations which only have dump to also be consistent.
> This removes unnecessary "_dump" from the names. There's a number
> of GET ops in classic Netlink which only have dump handlers.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
>  tools/net/ynl/pyynl/ynl_gen_c.py | 14 +++++++++-----
>  1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/tools/net/ynl/pyynl/ynl_gen_c.py b/tools/net/ynl/pyynl/ynl_gen_c.py
> index b0b47a493a86..c97cda43a604 100755
> --- a/tools/net/ynl/pyynl/ynl_gen_c.py
> +++ b/tools/net/ynl/pyynl/ynl_gen_c.py
> @@ -1212,6 +1212,7 @@ from lib import SpecFamily, SpecAttrSet, SpecAttr, SpecOperation, SpecEnumSet, S
>  
>          # 'do' and 'dump' response parsing is identical
>          self.type_consistent = True
> +        self.type_onside = False

I'm not understanding what type_onside is meant to mean.

Re: [PATCH net-next 10/13] tools: ynl-gen: consider dump ops without a do "type-consistent"

[Jakub Kicinski]

On Wed, 09 Apr 2025 13:38:01 +0100 Donald Hunter wrote:
> >          # 'do' and 'dump' response parsing is identical
> >          self.type_consistent = True
> > +        self.type_onside = False  
> 
> I'm not understanding what type_onside is meant to mean.

Damn, I have fallen into the IDE auto-completion trap.
It was supposed to say "oneside".
Not that the solution is super clean either way :(
-- 
pw-bot: cr

Re: [PATCH net-next 10/13] tools: ynl-gen: consider dump ops without a do "type-consistent"

[Jacob Keller]

On 4/9/2025 6:52 AM, Jakub Kicinski wrote:
> On Wed, 09 Apr 2025 13:38:01 +0100 Donald Hunter wrote:
>>>          # 'do' and 'dump' response parsing is identical
>>>          self.type_consistent = True
>>> +        self.type_onside = False  
>>
>> I'm not understanding what type_onside is meant to mean.
> 
> Damn, I have fallen into the IDE auto-completion trap.
> It was supposed to say "oneside".
> Not that the solution is super clean either way :(

Lol.. I saw this and read it as "type_oneside" myself.. didn't even
notice the typo.

[PATCH net-next 11/13] tools: ynl-gen: use family c-name in notifications

[Jakub Kicinski]

Family names may include dashes. Fix notification handling
code gen to the c-compatible name.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
 tools/net/ynl/pyynl/ynl_gen_c.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/net/ynl/pyynl/ynl_gen_c.py b/tools/net/ynl/pyynl/ynl_gen_c.py
index c97cda43a604..5fa1db3d5cf3 100755
--- a/tools/net/ynl/pyynl/ynl_gen_c.py
+++ b/tools/net/ynl/pyynl/ynl_gen_c.py
@@ -2726,7 +2726,7 @@ _C_KW = {
         return
 
     if family.ntfs:
-        cw.block_start(line=f"static const struct ynl_ntf_info {family['name']}_ntf_info[] = ")
+        cw.block_start(line=f"static const struct ynl_ntf_info {family.c_name}_ntf_info[] = ")
         for ntf_op_name, ntf_op in family.ntfs.items():
             if 'notify' in ntf_op:
                 op = family.ops[ntf_op['notify']]
@@ -2756,8 +2756,8 @@ _C_KW = {
     else:
         cw.p('.hdr_len\t= sizeof(struct genlmsghdr),')
     if family.ntfs:
-        cw.p(f".ntf_info\t= {family['name']}_ntf_info,")
-        cw.p(f".ntf_info_size\t= YNL_ARRAY_SIZE({family['name']}_ntf_info),")
+        cw.p(f".ntf_info\t= {family.c_name}_ntf_info,")
+        cw.p(f".ntf_info_size\t= YNL_ARRAY_SIZE({family.c_name}_ntf_info),")
     cw.block_end(line=';')
 
 
-- 
2.49.0

Re: [PATCH net-next 11/13] tools: ynl-gen: use family c-name in notifications

[Jacob Keller]

On 4/8/2025 5:03 PM, Jakub Kicinski wrote:
> Family names may include dashes. Fix notification handling
> code gen to the c-compatible name.
> 
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>

Re: [PATCH net-next 11/13] tools: ynl-gen: use family c-name in notifications

[Donald Hunter]

Jakub Kicinski <kuba@kernel.org> writes:

> Family names may include dashes. Fix notification handling
> code gen to the c-compatible name.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Reviewed-by: Donald Hunter <donald.hunter@gmail.com>

[PATCH net-next 12/13] tools: ynl: generate code for rt-addr and add a sample

[Jakub Kicinski]

YNL C can now generate code for simple classic netlink families.
Include rt-addr in the Makefile for generation and add a sample.

  $ ./tools/net/ynl/samples/rt-addr
              lo: 127.0.0.1
       wlp0s20f3: 192.168.1.101
              lo: ::
       wlp0s20f3: fe80::6385:be6:746e:8116
            vpn0: fe80::3597:d353:b5a7:66dd

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
 tools/net/ynl/Makefile.deps      |  1 +
 tools/net/ynl/generated/Makefile |  2 +-
 tools/net/ynl/samples/rt-addr.c  | 80 ++++++++++++++++++++++++++++++++
 tools/net/ynl/samples/.gitignore |  3 +-
 4 files changed, 84 insertions(+), 2 deletions(-)
 create mode 100644 tools/net/ynl/samples/rt-addr.c

diff --git a/tools/net/ynl/Makefile.deps b/tools/net/ynl/Makefile.deps
index f3269ce39e5b..e55d94211df6 100644
--- a/tools/net/ynl/Makefile.deps
+++ b/tools/net/ynl/Makefile.deps
@@ -29,4 +29,5 @@ CFLAGS_nfsd:=$(call get_hdr_inc,_LINUX_NFSD_NETLINK_H,nfsd_netlink.h)
 CFLAGS_ovs_datapath:=$(call get_hdr_inc,__LINUX_OPENVSWITCH_H,openvswitch.h)
 CFLAGS_ovs_flow:=$(call get_hdr_inc,__LINUX_OPENVSWITCH_H,openvswitch.h)
 CFLAGS_ovs_vport:=$(call get_hdr_inc,__LINUX_OPENVSWITCH_H,openvswitch.h)
+CFLAGS_rt-addr:=$(call get_hdr_inc,__LINUX_RTNETLINK_H,rtnetlink.h)
 CFLAGS_tcp_metrics:=$(call get_hdr_inc,_LINUX_TCP_METRICS_H,tcp_metrics.h)
diff --git a/tools/net/ynl/generated/Makefile b/tools/net/ynl/generated/Makefile
index 21f9e299dc75..67ce3b8988ef 100644
--- a/tools/net/ynl/generated/Makefile
+++ b/tools/net/ynl/generated/Makefile
@@ -25,7 +25,7 @@ SPECS_DIR:=../../../../Documentation/netlink/specs
 GENS_PATHS=$(shell grep -nrI --files-without-match \
 		'protocol: netlink' \
 		$(SPECS_DIR))
-GENS=$(patsubst $(SPECS_DIR)/%.yaml,%,${GENS_PATHS})
+GENS=$(patsubst $(SPECS_DIR)/%.yaml,%,${GENS_PATHS}) rt-addr
 SRCS=$(patsubst %,%-user.c,${GENS})
 HDRS=$(patsubst %,%-user.h,${GENS})
 OBJS=$(patsubst %,%-user.o,${GENS})
diff --git a/tools/net/ynl/samples/rt-addr.c b/tools/net/ynl/samples/rt-addr.c
new file mode 100644
index 000000000000..c9a6436ad420
--- /dev/null
+++ b/tools/net/ynl/samples/rt-addr.c
@@ -0,0 +1,80 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <stdio.h>
+#include <string.h>
+
+#include <ynl.h>
+
+#include <arpa/inet.h>
+#include <net/if.h>
+
+#include "rt-addr-user.h"
+
+static void rt_addr_print(struct rt_addr_getaddr_rsp *a, unsigned int op)
+{
+	char ifname[IF_NAMESIZE];
+	char addr_str[64];
+	const char *addr;
+	const char *name;
+
+	name = if_indextoname(a->_hdr.ifa_index, ifname);
+	if (name)
+		printf("%16s: ", name);
+
+	switch (a->_present.address_len) {
+	case 4:
+		addr = inet_ntop(AF_INET, a->address,
+				 addr_str, sizeof(addr_str));
+		break;
+	case 16:
+		addr = inet_ntop(AF_INET6, a->address,
+				 addr_str, sizeof(addr_str));
+		break;
+	default:
+		addr = NULL;
+		break;
+	}
+	if (addr)
+		printf("%s", addr);
+	else
+		printf("[%d]", a->_present.address_len);
+
+	printf("\n");
+}
+
+int main(int argc, char **argv)
+{
+	struct rt_addr_getaddr_list *rsp;
+	struct rt_addr_getaddr_req *req;
+	struct ynl_error yerr;
+	struct ynl_sock *ys;
+
+	ys = ynl_sock_create(&ynl_rt_addr_family, &yerr);
+	if (!ys) {
+		fprintf(stderr, "YNL: %s\n", yerr.msg);
+		return 1;
+	}
+
+	req = rt_addr_getaddr_req_alloc();
+	if (!req)
+		goto err_destroy;
+
+	rsp = rt_addr_getaddr_dump(ys, req);
+	rt_addr_getaddr_req_free(req);
+	if (!rsp)
+		goto err_close;
+
+	if (ynl_dump_empty(rsp))
+		fprintf(stderr, "Error: no addresses reported\n");
+	ynl_dump_foreach(rsp, addr)
+		rt_addr_print(addr, 0);
+	rt_addr_getaddr_list_free(rsp);
+
+	ynl_sock_destroy(ys);
+	return 0;
+
+err_close:
+	fprintf(stderr, "YNL: %s\n", ys->err.msg);
+err_destroy:
+	ynl_sock_destroy(ys);
+	return 2;
+}
diff --git a/tools/net/ynl/samples/.gitignore b/tools/net/ynl/samples/.gitignore
index dda6686257a7..2bc8721d6144 100644
--- a/tools/net/ynl/samples/.gitignore
+++ b/tools/net/ynl/samples/.gitignore
@@ -2,4 +2,5 @@ ethtool
 devlink
 netdev
 ovs
-page-pool
\ No newline at end of file
+page-pool
+rt-addr
-- 
2.49.0

Re: [PATCH net-next 12/13] tools: ynl: generate code for rt-addr and add a sample

[Jacob Keller]

On 4/8/2025 5:03 PM, Jakub Kicinski wrote:
> diff --git a/tools/net/ynl/samples/rt-addr.c b/tools/net/ynl/samples/rt-addr.c
> new file mode 100644
> index 000000000000..c9a6436ad420
> --- /dev/null
> +++ b/tools/net/ynl/samples/rt-addr.c
> @@ -0,0 +1,80 @@
> +int main(int argc, char **argv)
> +{
> +	struct rt_addr_getaddr_list *rsp;
> +	struct rt_addr_getaddr_req *req;
> +	struct ynl_error yerr;
> +	struct ynl_sock *ys;
> +
> +	ys = ynl_sock_create(&ynl_rt_addr_family, &yerr);
> +	if (!ys) {
> +		fprintf(stderr, "YNL: %s\n", yerr.msg);
> +		return 1;
> +	}
> +
> +	req = rt_addr_getaddr_req_alloc();
> +	if (!req)
> +		goto err_destroy;
> +
> +	rsp = rt_addr_getaddr_dump(ys, req);
> +	rt_addr_getaddr_req_free(req);
> +	if (!rsp)
> +		goto err_close;
> +
> +	if (ynl_dump_empty(rsp))
> +		fprintf(stderr, "Error: no addresses reported\n");
> +	ynl_dump_foreach(rsp, addr)
> +		rt_addr_print(addr, 0);
> +	rt_addr_getaddr_list_free(rsp);
> +
> +	ynl_sock_destroy(ys);
> +	return 0;
> +
> +err_close:
> +	fprintf(stderr, "YNL: %s\n", ys->err.msg);
> +err_destroy:
> +	ynl_sock_destroy(ys);
> +	return 2;
> +}
Nice! This makes it a lot simpler to write small tools for dedicated
tasks or debugging vs trying to use one of the other existing libraries.
I think it helps make netlink more accessible, and appreciate the work
to support the classic netlink families, even with their quirks.

Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>

Thanks,
Jake

Re: [PATCH net-next 12/13] tools: ynl: generate code for rt-addr and add a sample

[Jakub Kicinski]

On Tue, 8 Apr 2025 22:04:46 -0700 Jacob Keller wrote:
> Nice! This makes it a lot simpler to write small tools for dedicated
> tasks or debugging vs trying to use one of the other existing libraries.
> I think it helps make netlink more accessible, and appreciate the work
> to support the classic netlink families, even with their quirks.

I hope so! I must say, I'm a bit surprised that we don't see people
writing code gens for other languages. It is quite fun.

Re: [PATCH net-next 12/13] tools: ynl: generate code for rt-addr and add a sample

[Donald Hunter]

Jakub Kicinski <kuba@kernel.org> writes:

> YNL C can now generate code for simple classic netlink families.
> Include rt-addr in the Makefile for generation and add a sample.
>
>   $ ./tools/net/ynl/samples/rt-addr
>               lo: 127.0.0.1
>        wlp0s20f3: 192.168.1.101
>               lo: ::
>        wlp0s20f3: fe80::6385:be6:746e:8116
>             vpn0: fe80::3597:d353:b5a7:66dd
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Reviewed-by: Donald Hunter <donald.hunter@gmail.com>

[PATCH net-next 13/13] tools: ynl: generate code for rt-route and add a sample

[Jakub Kicinski]

YNL C can now generate code for simple classic netlink families.
Include rt-route in the Makefile for generation and add a sample.

    $ ./tools/net/ynl/samples/rt-route
    oif: wlp0s20f3        gateway: 192.168.1.1
    oif: wlp0s20f3        dst: 192.168.1.0/24
    oif: vpn0             dst: fe80::/64
    oif: wlp0s20f3        dst: fe80::/64
    oif: wlp0s20f3        gateway: fe80::200:5eff:fe00:201

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
 tools/net/ynl/Makefile.deps      |  1 +
 tools/net/ynl/generated/Makefile |  2 +-
 tools/net/ynl/samples/rt-route.c | 80 ++++++++++++++++++++++++++++++++
 tools/net/ynl/samples/.gitignore |  1 +
 4 files changed, 83 insertions(+), 1 deletion(-)
 create mode 100644 tools/net/ynl/samples/rt-route.c

diff --git a/tools/net/ynl/Makefile.deps b/tools/net/ynl/Makefile.deps
index e55d94211df6..385783489f84 100644
--- a/tools/net/ynl/Makefile.deps
+++ b/tools/net/ynl/Makefile.deps
@@ -30,4 +30,5 @@ CFLAGS_ovs_datapath:=$(call get_hdr_inc,__LINUX_OPENVSWITCH_H,openvswitch.h)
 CFLAGS_ovs_flow:=$(call get_hdr_inc,__LINUX_OPENVSWITCH_H,openvswitch.h)
 CFLAGS_ovs_vport:=$(call get_hdr_inc,__LINUX_OPENVSWITCH_H,openvswitch.h)
 CFLAGS_rt-addr:=$(call get_hdr_inc,__LINUX_RTNETLINK_H,rtnetlink.h)
+CFLAGS_rt-route:=$(call get_hdr_inc,__LINUX_RTNETLINK_H,rtnetlink.h)
 CFLAGS_tcp_metrics:=$(call get_hdr_inc,_LINUX_TCP_METRICS_H,tcp_metrics.h)
diff --git a/tools/net/ynl/generated/Makefile b/tools/net/ynl/generated/Makefile
index 67ce3b8988ef..6603ad8d4ce1 100644
--- a/tools/net/ynl/generated/Makefile
+++ b/tools/net/ynl/generated/Makefile
@@ -25,7 +25,7 @@ SPECS_DIR:=../../../../Documentation/netlink/specs
 GENS_PATHS=$(shell grep -nrI --files-without-match \
 		'protocol: netlink' \
 		$(SPECS_DIR))
-GENS=$(patsubst $(SPECS_DIR)/%.yaml,%,${GENS_PATHS}) rt-addr
+GENS=$(patsubst $(SPECS_DIR)/%.yaml,%,${GENS_PATHS}) rt-addr rt-route
 SRCS=$(patsubst %,%-user.c,${GENS})
 HDRS=$(patsubst %,%-user.h,${GENS})
 OBJS=$(patsubst %,%-user.o,${GENS})
diff --git a/tools/net/ynl/samples/rt-route.c b/tools/net/ynl/samples/rt-route.c
new file mode 100644
index 000000000000..9d9c868f8873
--- /dev/null
+++ b/tools/net/ynl/samples/rt-route.c
@@ -0,0 +1,80 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <stdio.h>
+#include <string.h>
+
+#include <ynl.h>
+
+#include <arpa/inet.h>
+#include <net/if.h>
+
+#include "rt-route-user.h"
+
+static void rt_route_print(struct rt_route_getroute_rsp *r)
+{
+	char ifname[IF_NAMESIZE];
+	char route_str[64];
+	const char *route;
+	const char *name;
+
+	/* Ignore local */
+	if (r->_hdr.rtm_table == RT_TABLE_LOCAL)
+		return;
+
+	if (r->_present.oif) {
+		name = if_indextoname(r->oif, ifname);
+		if (name)
+			printf("oif: %-16s ", name);
+	}
+
+	if (r->_present.dst_len) {
+		route = inet_ntop(r->_hdr.rtm_family, r->dst,
+				  route_str, sizeof(route_str));
+		printf("dst: %s/%d", route, r->_hdr.rtm_dst_len);
+	}
+
+	if (r->_present.gateway_len) {
+		route = inet_ntop(r->_hdr.rtm_family, r->gateway,
+				  route_str, sizeof(route_str));
+		printf("gateway: %s ", route);
+	}
+
+	printf("\n");
+}
+
+int main(int argc, char **argv)
+{
+	struct rt_route_getroute_req_dump *req;
+	struct rt_route_getroute_list *rsp;
+	struct ynl_error yerr;
+	struct ynl_sock *ys;
+
+	ys = ynl_sock_create(&ynl_rt_route_family, &yerr);
+	if (!ys) {
+		fprintf(stderr, "YNL: %s\n", yerr.msg);
+		return 1;
+	}
+
+	req = rt_route_getroute_req_dump_alloc();
+	if (!req)
+		goto err_destroy;
+
+	rsp = rt_route_getroute_dump(ys, req);
+	rt_route_getroute_req_dump_free(req);
+	if (!rsp)
+		goto err_close;
+
+	if (ynl_dump_empty(rsp))
+		fprintf(stderr, "Error: no routeesses reported\n");
+	ynl_dump_foreach(rsp, route)
+		rt_route_print(route);
+	rt_route_getroute_list_free(rsp);
+
+	ynl_sock_destroy(ys);
+	return 0;
+
+err_close:
+	fprintf(stderr, "YNL: %s\n", ys->err.msg);
+err_destroy:
+	ynl_sock_destroy(ys);
+	return 2;
+}
diff --git a/tools/net/ynl/samples/.gitignore b/tools/net/ynl/samples/.gitignore
index 2bc8721d6144..7f9781cf532f 100644
--- a/tools/net/ynl/samples/.gitignore
+++ b/tools/net/ynl/samples/.gitignore
@@ -4,3 +4,4 @@ netdev
 ovs
 page-pool
 rt-addr
+rt-route
-- 
2.49.0

Re: [PATCH net-next 13/13] tools: ynl: generate code for rt-route and add a sample

[Jacob Keller]

On 4/8/2025 5:04 PM, Jakub Kicinski wrote:
> YNL C can now generate code for simple classic netlink families.
> Include rt-route in the Makefile for generation and add a sample.
> 
>     $ ./tools/net/ynl/samples/rt-route
>     oif: wlp0s20f3        gateway: 192.168.1.1
>     oif: wlp0s20f3        dst: 192.168.1.0/24
>     oif: vpn0             dst: fe80::/64
>     oif: wlp0s20f3        dst: fe80::/64
>     oif: wlp0s20f3        gateway: fe80::200:5eff:fe00:201
> 
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>

Re: [PATCH net-next 13/13] tools: ynl: generate code for rt-route and add a sample

[Donald Hunter]

Jakub Kicinski <kuba@kernel.org> writes:

> YNL C can now generate code for simple classic netlink families.
> Include rt-route in the Makefile for generation and add a sample.
>
>     $ ./tools/net/ynl/samples/rt-route
>     oif: wlp0s20f3        gateway: 192.168.1.1
>     oif: wlp0s20f3        dst: 192.168.1.0/24
>     oif: vpn0             dst: fe80::/64
>     oif: wlp0s20f3        dst: fe80::/64
>     oif: wlp0s20f3        gateway: fe80::200:5eff:fe00:201
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Reviewed-by: Donald Hunter <donald.hunter@gmail.com>