Re: [RFC v5 0/5] Proposal to use netlink for RAS and Telemetry across drm subsystem

[Lukas Wunner <lukas@wunner.de>]

On Wed, Jul 30, 2025 at 12:19:51PM +0530, Aravind Iddamsetty wrote:
> Our hardware supports RAS(Reliability, Availability, Serviceability) by
> reporting the errors to the host, which the KMD processes and exposes a
> set of error counters which can be used by observability tools to take 
> corrective actions or repairs. Traditionally there were being exposed 
> via PMU (for relative counters) and sysfs interface (for absolute 
> value) in our internal branch. But, due to the limitations in this 
> approach to use two interfaces and also not able to have an event based 
> reporting or configurability, an alternative approach to try netlink 
> was suggested by community for drm subsystem wide UAPI for RAS and 
> telemetry as discussed in [2]. 
> 
> This [2] is the inspiration to this series. It uses the generic
> netlink(genl) family subsystem and exposes a set of commands that can
> be used by every drm driver, the framework provides a means to have
> custom commands too.

It seems this series was originally conceived in 2023.  In the meantime,
tooling has been introduced to auto-generate all the netlink boilerplate
code from a YAML description in Documentation/netlink/specs/.  I *think*
using it is mandatory for all newly introduced Netlink protocols.

Basically you create the uapi and kernel header files plus kernel source
like this:

tools/net/ynl/pyynl/ynl_gen_c.py --spec Documentation/netlink/specs/drm.yaml \
  --mode uapi --header
tools/net/ynl/pyynl/ynl_gen_c.py --spec Documentation/netlink/specs/drm.yaml \
  --mode kernel --header
tools/net/ynl/pyynl/ynl_gen_c.py --spec Documentation/netlink/specs/drm.yaml \
  --mode kernel --source

And then you add both the YAML file as well as the generated files to
the commit.  The reason you have to do that is because Python is
optional for building the kernel per Documentation/process/changes.rst,
so the files cannot be generated at compile time.  It is possible though
to regenerate them with tools/net/ynl/ynl-regen.sh whenever the YAML file
is changed.

ynl_gen_c.py is capable of auto-generating code for user space applications
as well.  And there's tools/net/ynl/pyynl/cli.py to listen to events or
send requests without having to write any code.

Thanks,

Lukas