[net-next,v3,00/12] tools/net/ynl: Add support for netlink-raw families

Message

Donald Hunter Aug. 22, 2023, 7:42 p.m. UTC

This patchset adds support for netlink-raw families such as rtnetlink.

Patch 1 fixes a typo in existing schemas
Patch 2 contains the schema definition
Patches 3 & 4 update the schema documentation
Patches 5 - 9 extends ynl
Patches 10 - 12 add several netlink-raw specs

The netlink-raw schema is very similar to genetlink-legacy and I thought
about making the changes there and symlinking to it. On balance I
thought that might be problematic for accurate schema validation.

rtnetlink doesn't seem to fit into unified or directional message
enumeration models. It seems like an 'explicit' model would be useful,
to force the schema author to specify the message ids directly.

There is not yet support for notifications because ynl currently doesn't
support defining 'event' properties on a 'do' operation. The message ids
are shared so ops need to be both sync and async. I plan to look at this
in a future patch.

The link and route messages contain different nested attributes
dependent on the type of link or route. Decoding these will need some
kind of attr-space selection that uses the value of another attribute as
the selector key. These nested attributes have been left with type
'binary' for now.

v2 -> v3:
  - Fix typo in existing schemas
  - Rework fixed_header code to fix extack parsing
  - Add support for CREATE, EXCL, REPLACE and APPEND, needed by rt_route

v1 -> v2:
  - Put mcast-group changes in separate patch
  - Put decode_fixed_header refactoring in separate patch
  - Avoid refactoring decode_enum
  - Rename NetlinkProtocolFamily -> NetlinkProtocol and
    GenlProtocolFamily -> GenlProtocol and store in self.nlproto
  - Add spec for rt link.

Donald Hunter (12):
  doc/netlink: Fix typo in genetlink-* schemas
  doc/netlink: Add a schema for netlink-raw families
  doc/netlink: Update genetlink-legacy documentation
  doc/netlink: Document the netlink-raw schema extensions
  tools/ynl: Add mcast-group schema parsing to ynl
  tools/net/ynl: Fix extack parsing with fixed header genlmsg
  tools/net/ynl: Add support for netlink-raw families
  tools/net/ynl: Implement nlattr array-nest decoding in ynl
  tools/net/ynl: Add support for create flags
  doc/netlink: Add spec for rt addr messages
  doc/netlink: Add spec for rt link messages
  doc/netlink: Add spec for rt route messages

 Documentation/core-api/netlink.rst            |    9 +-
 Documentation/netlink/genetlink-c.yaml        |    2 +-
 Documentation/netlink/genetlink-legacy.yaml   |    2 +-
 Documentation/netlink/netlink-raw.yaml        |  414 +++++
 Documentation/netlink/specs/rt_addr.yaml      |  179 +++
 Documentation/netlink/specs/rt_link.yaml      | 1376 +++++++++++++++++
 Documentation/netlink/specs/rt_route.yaml     |  306 ++++
 .../netlink/genetlink-legacy.rst              |   26 +-
 Documentation/userspace-api/netlink/index.rst |    1 +
 .../userspace-api/netlink/netlink-raw.rst     |   58 +
 Documentation/userspace-api/netlink/specs.rst |   13 +
 tools/net/ynl/cli.py                          |   12 +-
 tools/net/ynl/lib/__init__.py                 |    4 +-
 tools/net/ynl/lib/nlspec.py                   |   31 +
 tools/net/ynl/lib/ynl.py                      |  196 ++-
 15 files changed, 2557 insertions(+), 72 deletions(-)
 create mode 100644 Documentation/netlink/netlink-raw.yaml
 create mode 100644 Documentation/netlink/specs/rt_addr.yaml
 create mode 100644 Documentation/netlink/specs/rt_link.yaml
 create mode 100644 Documentation/netlink/specs/rt_route.yaml
 create mode 100644 Documentation/userspace-api/netlink/netlink-raw.rst

Comments

Jakub Kicinski Aug. 23, 2023, 2:03 a.m. UTC | #1

On Tue, 22 Aug 2023 20:42:52 +0100 Donald Hunter wrote:
> The netlink-raw schema is very similar to genetlink-legacy and I thought
> about making the changes there and symlinking to it. On balance I
> thought that might be problematic for accurate schema validation.
> 
> rtnetlink doesn't seem to fit into unified or directional message
> enumeration models. It seems like an 'explicit' model would be useful,
> to force the schema author to specify the message ids directly.
> 
> There is not yet support for notifications because ynl currently doesn't
> support defining 'event' properties on a 'do' operation. The message ids
> are shared so ops need to be both sync and async. I plan to look at this
> in a future patch.
> 
> The link and route messages contain different nested attributes
> dependent on the type of link or route. Decoding these will need some
> kind of attr-space selection that uses the value of another attribute as
> the selector key. These nested attributes have been left with type
> 'binary' for now.

Looks good, thanks!