From: Laura Nao <laura.nao@collabora.com>
To: dakr@kernel.org, aliceryhl@google.com, airlied@gmail.com,
simona@ffwll.ch, ojeda@kernel.org, boqun@kernel.org,
gary@garyguo.net, bjorn3_gh@protonmail.com, lossin@kernel.org,
a.hindborg@kernel.org, tmgross@umich.edu,
boris.brezillon@collabora.com
Cc: dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
kernel@collabora.com, Laura Nao <laura.nao@collabora.com>
Subject: [PATCH v2 0/1] DRM 'feature' support for DRM drivers
Date: Tue, 5 May 2026 11:23:03 +0200 [thread overview]
Message-ID: <20260505092304.108262-1-laura.nao@collabora.com> (raw)
This is a follow up to [1], which introduces feature support for DRM
drivers, as will soon be needed by Tyr and rvkms.
Based on feedback and discussion on the first iteration, render node
support has been reworked.
Support for render nodes was initially modeled as an unsafe trait, to
require drivers to comply with any safety requirements tied to enabling
a given feature. For DRIVER_RENDER specifically, the intent was to force
implementors to ensure that any ioctl declared with DRM_RENDER_ALLOW
does not call KMS/modesetting APIs or require DRM_MASTER.
However, the C DRM core already enforces render node access control at
the ioctl dispatch level: if a client opens a render node, any ioctl
without the DRM_RENDER_ALLOW flag will fail. So the C DRM framework
already ensures the rules are respected for core ioctls, and the
unsafe trait doesn't add any meaningful protection beyond this.
For these reasons and since enabling DRIVER_RENDER doesn't require any
particular method to be implemented, there's no real need to model this
as a trait, and a boolean flag is sufficient.
This does not prevent other driver features to be modeled differently
based on their requirements. Features that require additional ops (e.g.
FEAT_MODESET) could instead be modeled as a trait, and some other
constant type that can only be constructed when the relevant trait is
implemented.
Introducing the RENDER_CAPABILITY bool flag here leaves room for
implementing other features differently at a later stage.
Changes since v1:
- Replaced DriverFeatures trait and ZSTs with single
RENDER_CAPABILITY: bool constant
- Squashed changes into a single patch
[1] v1: https://lore.kernel.org/rust-for-linux/20260119-drm-render-v1-0-8326e4d5cb44@collabora.com/
Laura Nao (1):
rust: drm: add RENDER_CAPABILITY flag for render node support
drivers/gpu/drm/tyr/driver.rs | 1 +
rust/kernel/drm/device.rs | 12 +++++++++++-
rust/kernel/drm/driver.rs | 5 +++++
3 files changed, 17 insertions(+), 1 deletion(-)
--
2.39.5
next reply other threads:[~2026-05-05 9:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-05 9:23 Laura Nao [this message]
2026-05-05 9:23 ` [PATCH v2 1/1] rust: drm: add RENDER_CAPABILITY flag for render node support Laura Nao
2026-05-05 10:54 ` Alice Ryhl
2026-05-06 8:41 ` Laura Nao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260505092304.108262-1-laura.nao@collabora.com \
--to=laura.nao@collabora.com \
--cc=a.hindborg@kernel.org \
--cc=airlied@gmail.com \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=boris.brezillon@collabora.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=kernel@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=tmgross@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox