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

[Aravind Iddamsetty]

On 31-07-2025 02:30, Lukas Wunner wrote:
> 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.

Thanks Lukas letting me know this. Will do the necessary.

Regards,
Aravind.
>
> 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