Use existing render group for fastrpc devices instead of creating a new fastrpc group

[ekanshibu]

The current post-install/udev flow creates a dedicated fastrpc system group and assigns /dev/fastrpc* devices to it via udev rules. Can we use the existing render group instead of creating and maintaining a separate fastrpc group?

[basak-qcom]

Thank you for filing this!

For reference, qcom-deb-images currently adds the default debian user to the render group. At the moment, nothing adds any user to the fastrpc group. That currently has to be done by the sysadmin which I agree is not a good UX.

The relevant code here is https://github.com/qualcomm-linux/pkg-fastrpc/blob/debian/new/debian/fastrpc-support.udev and https://github.com/qualcomm-linux/pkg-fastrpc/blob/debian/new/debian/fastrpc-support.postinst

[lool]

On top of "default user" scenarios, there is also typically logic based on the usage:

• when logging into a desktop session, or plugging devices dynamically, permissions get adjusted via facls
• when running containers, we map host devices to containers to let apps/workloads get hw acceleration

This a larger system architecture question than just the default user/default groups

[basak-qcom]

I'd like to ensure that this is a correct change to make before we make it. Dmitry plans to post with further justfication of why this is needed. Until we've figured that out and concluded that this is an appropriate change to make, we intend to keep the fastrpc group as it is.

[lumag]

Regarding the render vs fastrpc.

• The former group is the standard one, being a part of base-files. There is no need to create separate group. Users usually are already added to it, if they want to access GPU or NPU acceleration on the hosts (because it is used for rocket, etnaviv and other NPU drivers).
• For this reason there might be existing integrations, adding the first or the default user to that group. On the contrary, the fastrpc group is a non-standard solution, which should be completely handled on our own.
• The FastRPC hopefully migrates to drm/accel at some point. All drm/accel devices are owned by the render group (the default on Debian), at which point we will have to migrate to that group. Using accel group from the beginning is more future-proof and ensures seamless migration to accel driver in future.

[lool]

Regarding the render vs fastrpc.

• The former group is the standard one, being a part of base-files. There is no need to create separate group. Users usually are already added to it, if they want to access GPU or NPU acceleration on the hosts (because it is used for rocket, etnaviv and other NPU drivers).
• For this reason there might be existing integrations, adding the first or the default user to that group. On the contrary, the fastrpc group is a non-standard solution, which should be completely handled on our own.

With this logic, we'd never define anything new and we'd put everything under the same groups. NPU is a new class of hardware, we have different device nodes and groups for audio, display, GPU acceleration etc.

• The FastRPC hopefully migrates to drm/accel at some point. All drm/accel devices are owned by the render group (the default on Debian), at which point we will have to migrate to that group. Using accel group from the beginning is more future-proof and ensures seamless migration to accel driver in future.

That makes sense, and even if render is not a good name, it could make sense to keep using it even if it's more of accel in meaning.

Is the "accel" group being defined somewhere? I don't think it's in base-files yet either. Do we have a rough timeline for this? I guess this will also imply moving to new device nodes?

[basak-qcom]

The former group is the standard one, being a part of base-files.

I don't see it at https://salsa.debian.org/debian/base-passwd/-/blob/master/group.master?ref_type=heads, and it is missing from my unstable build chroots. So I don't think it's part of the base system. Of course something creates it, but I didn't find anything from a quick search and it needs a deeper look.

[lumag]

@basak-qcom hmm, interesting. I was sure that it is a part of base-files, because it's being handled by the standard udev rules. Then I'm sorry for the misinformation.

[lumag]

Is the "accel" group being defined somewhere? I don't think it's in base-files yet either. Do we have a rough timeline for this? I guess this will also imply moving to new device nodes?

Of course, I meant render group, sorry. It is being created from /usr/lib/sysusers.d/debian-udev.conf, the origin of the file is at https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/udev.debian-udev.sysusers?ref_type=heads

[lool]

My suggestion would be to make this configurable and cover the recommendations in an INTEGRATORS.md or similar readme. For instance, we could document and support running fastrpc-support as root, or as a specific user, and suggest the fastrpc name for now.

I understand we'll move to accel/render long-term, this seems to be some time away, and I'm also not clear on the implications for device nodes; I get the impression there will be two sets of nodes in the future: the /dev/fastrpc ones for backwards compat and to address things running at the fastrpc transport level, and /dev/drm nodes that will be used instead of DMABUF. IIUC this future world, we could have the drm nodes under the render group, add the fastrpc daemon user to that group, and keep the fastrpc nodes as fastrpc:fastrpc.

[basak-qcom]

Is configurability by using the usual mechanism to override udev rules sufficient? Would you want the documentation in packaging (eg. README.Debian) or upstream?

[lool]

I think this is an upstream topic where we should provide recommendations on how we think fastrpc should be integrated, leaving room for distro divergence where needed.

[github-actions]

This issue has been marked as stale due to 60 days of inactivity. To prevent automatic closure in 10 days, remove the stale label or add a comment. You can reopen a closed issue at any time.