On Thu, Oct 02, 2025 at 02:38:47PM -0600, Zack McKevitt wrote:
> I think this looks good, adding telemetry functionality as a node type and
> in the yaml spec looks straightforward (despite some potential naming
> awkwardness with the RAS module). Thanks for adding this.
> 
> Have you considered how this might work for containerized workloads?

>From the use cases that we have, we are already expecting network=host,
so there shouldn't be any problem for this usage.

> Specifically, I think it would be best if the underlying drm_ras nodes are
> only accessible for containerized workloads where the device has been
> explicitly passed in. Do you know if this is handled automatically with the
> existing netlink implementation? I imagine that this would be of interest to
> the broader community outside of Qualcomm as well.

My understanding is that it is. But adding the netlink mailing list and 
maintainers
here for more specialized eyes.

> 
> > Also, it is worth to mention that we have a in-tree pyynl/cli.py tool that 
> > entirely
> > exercises this new API, hence I hope this can be the reference code for the 
> > uAPI
> > usage, while we continue with the plan of introducing IGT tests and tools 
> > for this
> > and adjusting the internal vendor tools to open with open source 
> > developments and
> > changing them to support these flows.
> 
> I think it would be nice to see some accompanying userspace code that makes
> use of this implementation to have as a reference if at all possible.

We have some folks working on the userspace tools, but I just realized that
perhaps we don't even need that and we could perhaps only using the
kernel-tools/ynl as official drm-ras consumer?

$ sudo ynl --family drm_ras --dump list-nodes
[{'device-name': '00:02.0',
  'node-id': 0,
  'node-name': 'non-fatal',
  'node-type': 'error-counter'},
 {'device-name': '00:02.0',
  'node-id': 1,
  'node-name': 'correctable',
 'node-type': 'error-counter'}]

thoughts?

> 
> As a side note, I will be on vacation for a couple of weeks as of this
> weekend and my response time will be affected.

Thank you,
Please let me know if you have further thoughts here, or if you see any blocker
or an ack to move forward with this path.

Thanks,
Rodrigo.

> 
> Thanks,
> 
> Zack

Reply via email to