lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20260119-drm-render-v1-0-8326e4d5cb44@collabora.com>
Date: Mon, 19 Jan 2026 20:34:45 -0300
From: Daniel Almeida <daniel.almeida@...labora.com>
To: Danilo Krummrich <dakr@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>, 
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, 
 Daniel Almeida <daniel.almeida@...labora.com>, 
 Miguel Ojeda <ojeda@...nel.org>, Boqun Feng <boqun.feng@...il.com>, 
 Gary Guo <gary@...yguo.net>, 
 Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
 Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>, 
 Trevor Gross <tmgross@...ch.edu>, 
 Boris Brezillon <boris.brezillon@...labora.com>
Cc: nouveau@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org, 
 linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org
Subject: [PATCH 0/2] DRM 'feature' support for DRM drivers

This series introduces feature support for DRM drivers, as this will soon
be needed by Tyr and rvkms.

Patch 1 introduces the unsafe DriverFeatures trait. It underpins the design
by forcing drivers to comply with its safety requirements when enabling
features. It also introduces the compute_features() helper in order to
centralize the decision of which features to enable based on the value of
FeatureFoo::ENABLED.

Patch two showcases the design by implementing FEAT_RENDER. This adds a
safety requirement to the DriverFeatures trait that applies when the
corresponding feature is enabled. It is enabled on Tyr while Nova defaults
to NoRender, as it's unclear whether it's something that they want to
enable at the moment. This has the bonus of highlighting how features can
be disabled in a given driver in a non-disruptive manner.

Optionally, features can require that additional traits be implemented.
These traits may come with their own safety requirements and the type
system will ensure that they're indeed implemented if the feature is
enabled by the driver.

The commit message for patch one describes how this can be achieved in
rough terms. It's not a reference, though, as a lot of the boilerplate was
omitted for brevity. In any case, I tested an imaginary "ModesetOps" trait
in both Tyr and Nova and everything seems to work from a type system's
perspective.

Finally, the current approach is extensible as new features can be
described with traits and types without disrupting existing ones. They can
also convey their own safety requirements and even their own API, as
described above.

Please feel free to suggest new names for any of the types or patterns
used. They're somewhat illustrative and not intended as final.

---
Daniel Almeida (2):
      rust: drm: add support for driver features
      rust: drm: add FeatureRender

 drivers/gpu/drm/nova/driver.rs |  7 ++++++
 drivers/gpu/drm/tyr/driver.rs  | 11 +++++++++
 rust/kernel/drm/device.rs      | 14 +++++++++++-
 rust/kernel/drm/driver.rs      | 52 +++++++++++++++++++++++++++++++++++++++++-
 4 files changed, 82 insertions(+), 2 deletions(-)
---
base-commit: 0f61b1860cc3f52aef9036d7235ed1f017632193
change-id: 20260116-drm-render-e85e615641f6

Best regards,
-- 
Daniel Almeida <daniel.almeida@...labora.com>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ