* [PATCH 0/2] DRM 'feature' support for DRM drivers
@ 2026-01-19 23:34 Daniel Almeida
2026-01-19 23:34 ` [PATCH 1/2] rust: drm: add support for driver features Daniel Almeida
2026-01-19 23:34 ` [PATCH 2/2] rust: drm: add FeatureRender Daniel Almeida
0 siblings, 2 replies; 6+ messages in thread
From: Daniel Almeida @ 2026-01-19 23:34 UTC (permalink / raw)
To: Danilo Krummrich, Alice Ryhl, David Airlie, Simona Vetter,
Daniel Almeida, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Boris Brezillon
Cc: nouveau, dri-devel, linux-kernel, rust-for-linux
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@collabora.com>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH 1/2] rust: drm: add support for driver features
2026-01-19 23:34 [PATCH 0/2] DRM 'feature' support for DRM drivers Daniel Almeida
@ 2026-01-19 23:34 ` Daniel Almeida
2026-01-21 17:31 ` Gary Guo
2026-01-19 23:34 ` [PATCH 2/2] rust: drm: add FeatureRender Daniel Almeida
1 sibling, 1 reply; 6+ messages in thread
From: Daniel Almeida @ 2026-01-19 23:34 UTC (permalink / raw)
To: Danilo Krummrich, Alice Ryhl, David Airlie, Simona Vetter,
Daniel Almeida, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Boris Brezillon
Cc: nouveau, dri-devel, linux-kernel, rust-for-linux
Add initial support for drm driver features via the DriverFeatures trait.
This trait is unsafe, requiring the implementer to comply with the safety
requirements of each feature individually if the feature is enabled.
New features can be described by adding separate ZSTs to encode them. The
current design assumes two types, for example: FeatureFooSupported and
NoFoo. As said above, this will require implementors to observe more safety
requirements in their DriverFeatures trait implementation.
A subsequent commit will build on this one to add support for FEAT_RENDER.
This is required by Tyr and other drivers.
Additionally, features can also require additional traits to be implemented
when enabled. These traits can add their own safety requirements.
This is roughly described below, with some boilerplate omitted:
pub struct ModesetSupported;
pub struct NoModeset;
pub unsafe trait ModesetOps: Driver {
fn set_mode(&self, ...);
}
pub trait ModesetRequirement<F: ModesetFeature> {}
impl<T: ModesetOps> ModesetRequirement<ModesetSupported> for T {}
impl<T> ModesetRequirement<NoModeset> for T {}
pub trait Driver:
DriverFeatures
+ ModesetRequirement<Self::Modeset>
{
// ...
}
// `driver::compute_features` is augmented to include the feature flag.
const fn compute_features() -> u32 {
if T::Modeset::ENABLED {
features |= FEAT_MODESET;
}
features
}
// In driver code, `DriverFeatures` can enable the feature via
// `ModesetSupported`.
unsafe impl DriverFeatures for MyDriver {
type Modeset = ModesetSupported;
}
// Required because `Modeset = ModesetSupported`.
unsafe impl ModesetOps for MyDriver {...}
Feature support will soon be required by upcoming DRM drivers. This
extensible model lets us describe them in terms of either additional safety
requirements and/or traits.
Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
---
drivers/gpu/drm/nova/driver.rs | 5 +++++
drivers/gpu/drm/tyr/driver.rs | 5 +++++
rust/kernel/drm/device.rs | 6 +++++-
rust/kernel/drm/driver.rs | 17 ++++++++++++++++-
4 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nova/driver.rs b/drivers/gpu/drm/nova/driver.rs
index 2246d8e104e0..247a05f7b3a7 100644
--- a/drivers/gpu/drm/nova/driver.rs
+++ b/drivers/gpu/drm/nova/driver.rs
@@ -69,3 +69,8 @@ impl drm::Driver for NovaDriver {
(NOVA_GEM_INFO, drm_nova_gem_info, ioctl::AUTH | ioctl::RENDER_ALLOW, File::gem_info),
}
}
+
+// SAFETY: This trait requires implementers to observe the safety requirements
+// of each enabled feature. There are no features enabled, so this is safe by
+// definition.
+unsafe impl drm::driver::DriverFeatures for NovaDriver {}
diff --git a/drivers/gpu/drm/tyr/driver.rs b/drivers/gpu/drm/tyr/driver.rs
index 0389c558c036..ec2aa30515a1 100644
--- a/drivers/gpu/drm/tyr/driver.rs
+++ b/drivers/gpu/drm/tyr/driver.rs
@@ -191,6 +191,11 @@ impl drm::Driver for TyrDriver {
}
}
+// SAFETY: This trait requires implementers to observe the safety requirements
+// of each enabled feature. There are no features enabled, so this is safe by
+// definition.
+unsafe impl drm::driver::DriverFeatures for TyrDriver {}
+
#[pin_data]
struct Clocks {
core: Clk,
diff --git a/rust/kernel/drm/device.rs b/rust/kernel/drm/device.rs
index 3ce8f62a0056..cfc2f34e8cc2 100644
--- a/rust/kernel/drm/device.rs
+++ b/rust/kernel/drm/device.rs
@@ -61,6 +61,10 @@ pub struct Device<T: drm::Driver> {
}
impl<T: drm::Driver> Device<T> {
+ const fn compute_features() -> u32 {
+ drm::driver::FEAT_GEM
+ }
+
const VTABLE: bindings::drm_driver = drm_legacy_fields! {
load: None,
open: Some(drm::File::<T::File>::open_callback),
@@ -86,7 +90,7 @@ impl<T: drm::Driver> Device<T> {
name: crate::str::as_char_ptr_in_const_context(T::INFO.name).cast_mut(),
desc: crate::str::as_char_ptr_in_const_context(T::INFO.desc).cast_mut(),
- driver_features: drm::driver::FEAT_GEM,
+ driver_features: Self::compute_features(),
ioctls: T::IOCTLS.as_ptr(),
num_ioctls: T::IOCTLS.len() as i32,
fops: &Self::GEM_FOPS,
diff --git a/rust/kernel/drm/driver.rs b/rust/kernel/drm/driver.rs
index f30ee4c6245c..fdfd083ba2b6 100644
--- a/rust/kernel/drm/driver.rs
+++ b/rust/kernel/drm/driver.rs
@@ -98,7 +98,7 @@ pub trait AllocImpl: super::private::Sealed + drm::gem::IntoGEMObject {
/// This trait must be implemented by drivers in order to create a `struct drm_device` and `struct
/// drm_driver` to be registered in the DRM subsystem.
#[vtable]
-pub trait Driver {
+pub trait Driver: DriverFeatures {
/// Context data associated with the DRM driver
type Data: Sync + Send;
@@ -168,3 +168,18 @@ fn drop(&mut self) {
unsafe { bindings::drm_dev_unregister(self.0.as_raw()) };
}
}
+
+/// Marker trait for drivers supporting specific features.
+///
+/// This trait is unsafe, and each feature might add its own safety
+/// requirements. The safety requirements for this trait requires the caller to
+/// comply with the safety requirements of each supported feature.
+///
+/// Features might also require additional trait implementations to be present.
+/// These additional traits may also be unsafe.
+///
+/// # Safety
+///
+/// Drivers implementing this trait must ensure they comply with the safety
+/// requirements of each supported feature.
+pub unsafe trait DriverFeatures {}
--
2.52.0
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH 2/2] rust: drm: add FeatureRender
2026-01-19 23:34 [PATCH 0/2] DRM 'feature' support for DRM drivers Daniel Almeida
2026-01-19 23:34 ` [PATCH 1/2] rust: drm: add support for driver features Daniel Almeida
@ 2026-01-19 23:34 ` Daniel Almeida
1 sibling, 0 replies; 6+ messages in thread
From: Daniel Almeida @ 2026-01-19 23:34 UTC (permalink / raw)
To: Danilo Krummrich, Alice Ryhl, David Airlie, Simona Vetter,
Daniel Almeida, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Boris Brezillon
Cc: nouveau, dri-devel, linux-kernel, rust-for-linux
Add a feature for drivers willing to expose render nodes to userspace. This
comes with an added safety requirement in the DriverFeatures trait. This,
in turn, exposes /dev/dri/renderDXX nodes that can be used by userspace to
control the device.
This is then enabled in the Tyr driver, while it's left as NoRender for
Nova for the time being.
Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
---
drivers/gpu/drm/nova/driver.rs | 4 +++-
drivers/gpu/drm/tyr/driver.rs | 12 +++++++++---
rust/kernel/drm/device.rs | 10 +++++++++-
rust/kernel/drm/driver.rs | 37 ++++++++++++++++++++++++++++++++++++-
4 files changed, 57 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nova/driver.rs b/drivers/gpu/drm/nova/driver.rs
index 247a05f7b3a7..4de1e4cfdc5d 100644
--- a/drivers/gpu/drm/nova/driver.rs
+++ b/drivers/gpu/drm/nova/driver.rs
@@ -73,4 +73,6 @@ impl drm::Driver for NovaDriver {
// SAFETY: This trait requires implementers to observe the safety requirements
// of each enabled feature. There are no features enabled, so this is safe by
// definition.
-unsafe impl drm::driver::DriverFeatures for NovaDriver {}
+unsafe impl drm::driver::DriverFeatures for NovaDriver {
+ type Render = drm::driver::NoRender;
+}
diff --git a/drivers/gpu/drm/tyr/driver.rs b/drivers/gpu/drm/tyr/driver.rs
index ec2aa30515a1..c12ad8467605 100644
--- a/drivers/gpu/drm/tyr/driver.rs
+++ b/drivers/gpu/drm/tyr/driver.rs
@@ -192,9 +192,15 @@ impl drm::Driver for TyrDriver {
}
// SAFETY: This trait requires implementers to observe the safety requirements
-// of each enabled feature. There are no features enabled, so this is safe by
-// definition.
-unsafe impl drm::driver::DriverFeatures for TyrDriver {}
+// of each enabled feature.
+//
+// For `FeatureRender`: we do not call modesetting APIs in our ioctls, and we do
+// not use any APIs requiring a DRM master. Furthermore, it is not possible for
+// a client to interfere in another client by design. This is enforced by the
+// `VM` layer and, at a lower level, by the system's IOMMU.
+unsafe impl drm::driver::DriverFeatures for TyrDriver {
+ type Render = drm::driver::RenderSupported;
+}
#[pin_data]
struct Clocks {
diff --git a/rust/kernel/drm/device.rs b/rust/kernel/drm/device.rs
index cfc2f34e8cc2..b2c2e6c195af 100644
--- a/rust/kernel/drm/device.rs
+++ b/rust/kernel/drm/device.rs
@@ -62,7 +62,15 @@ pub struct Device<T: drm::Driver> {
impl<T: drm::Driver> Device<T> {
const fn compute_features() -> u32 {
- drm::driver::FEAT_GEM
+ use crate::drm::driver::FeatureRender;
+
+ let mut features = drm::driver::FEAT_GEM;
+
+ if T::Render::ENABLED {
+ features |= drm::driver::FEAT_RENDER;
+ }
+
+ features
}
const VTABLE: bindings::drm_driver = drm_legacy_fields! {
diff --git a/rust/kernel/drm/driver.rs b/rust/kernel/drm/driver.rs
index fdfd083ba2b6..331a998e47e4 100644
--- a/rust/kernel/drm/driver.rs
+++ b/rust/kernel/drm/driver.rs
@@ -15,6 +15,9 @@
/// Driver use the GEM memory manager. This should be set for all modern drivers.
pub(crate) const FEAT_GEM: u32 = bindings::drm_driver_feature_DRIVER_GEM;
+/// Driver supports render nodes, i.e.: /dev/dri/renderDXX devices.
+pub(crate) const FEAT_RENDER: u32 = bindings::drm_driver_feature_DRIVER_RENDER;
+
/// Information data for a DRM Driver.
pub struct DriverInfo {
/// Driver major version.
@@ -182,4 +185,36 @@ fn drop(&mut self) {
///
/// Drivers implementing this trait must ensure they comply with the safety
/// requirements of each supported feature.
-pub unsafe trait DriverFeatures {}
+///
+/// - For drivers implementing `FeatureRender`:
+///
+/// The render-accessible subset of the driver's functionality must not allow
+/// clients to interfere with each other or require master privileges. In other
+/// words, any ioctl declared with [`drm::RENDER_ALLOW`] must not call any
+/// KMS/modesetting APIs or require `DRM_MASTER`.
+pub unsafe trait DriverFeatures {
+ /// Feature for render nodes.
+ type Render: FeatureRender;
+}
+
+/// Controls whether render nodes are supported via `Self::ENABLED`.
+pub trait FeatureRender: drm::private::Sealed {
+ /// Whether render nodes are enabled.
+ const ENABLED: bool;
+}
+
+/// A marker type indicating that the driver supports render nodes.
+pub struct RenderSupported;
+
+/// A marker type indicating that the driver does not support render nodes.
+pub struct NoRender;
+
+impl drm::private::Sealed for RenderSupported {}
+impl FeatureRender for RenderSupported {
+ const ENABLED: bool = true;
+}
+
+impl drm::private::Sealed for NoRender {}
+impl FeatureRender for NoRender {
+ const ENABLED: bool = false;
+}
--
2.52.0
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH 1/2] rust: drm: add support for driver features
2026-01-19 23:34 ` [PATCH 1/2] rust: drm: add support for driver features Daniel Almeida
@ 2026-01-21 17:31 ` Gary Guo
2026-01-21 19:05 ` Daniel Almeida
2026-05-05 10:13 ` Laura Nao
0 siblings, 2 replies; 6+ messages in thread
From: Gary Guo @ 2026-01-21 17:31 UTC (permalink / raw)
To: Daniel Almeida, Danilo Krummrich, Alice Ryhl, David Airlie,
Simona Vetter, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Boris Brezillon
Cc: nouveau, dri-devel, linux-kernel, rust-for-linux
On Mon Jan 19, 2026 at 11:34 PM GMT, Daniel Almeida wrote:
> Add initial support for drm driver features via the DriverFeatures trait.
> This trait is unsafe, requiring the implementer to comply with the safety
> requirements of each feature individually if the feature is enabled.
I think such unsafe requirement is quite vague and also very non-local.
Maybe we can use a single trait (the `ModesetOps` that you described) to do
this:
Something like:
pub unsafe trait ModesetOps<D> { ... }
// Maybe the never type in the future...
pub enum NoFeature {}
impl<D> ModesetOps<D> for NoFeature {
fn foo(&self, ...) { unimplemented!() }
}
impl Driver {
/// Reference the modeset implementation (typically Self),
/// or `NoFeature` to indicate that the feature is not implemented.
type Modeset: ModesetOps<Self>;
}
When building, you can use `TypeId` to check if it's actually implemented, and
set bits in the feature flags automatically.
Best,
Gary
>
> New features can be described by adding separate ZSTs to encode them. The
> current design assumes two types, for example: FeatureFooSupported and
> NoFoo. As said above, this will require implementors to observe more safety
> requirements in their DriverFeatures trait implementation.
>
> A subsequent commit will build on this one to add support for FEAT_RENDER.
> This is required by Tyr and other drivers.
>
> Additionally, features can also require additional traits to be implemented
> when enabled. These traits can add their own safety requirements.
>
> This is roughly described below, with some boilerplate omitted:
>
> pub struct ModesetSupported;
> pub struct NoModeset;
>
> pub unsafe trait ModesetOps: Driver {
> fn set_mode(&self, ...);
> }
>
> pub trait ModesetRequirement<F: ModesetFeature> {}
> impl<T: ModesetOps> ModesetRequirement<ModesetSupported> for T {}
> impl<T> ModesetRequirement<NoModeset> for T {}
>
> pub trait Driver:
> DriverFeatures
> + ModesetRequirement<Self::Modeset>
> {
> // ...
> }
>
> // `driver::compute_features` is augmented to include the feature flag.
> const fn compute_features() -> u32 {
> if T::Modeset::ENABLED {
> features |= FEAT_MODESET;
> }
>
> features
> }
>
> // In driver code, `DriverFeatures` can enable the feature via
> // `ModesetSupported`.
> unsafe impl DriverFeatures for MyDriver {
> type Modeset = ModesetSupported;
> }
>
> // Required because `Modeset = ModesetSupported`.
> unsafe impl ModesetOps for MyDriver {...}
>
> Feature support will soon be required by upcoming DRM drivers. This
> extensible model lets us describe them in terms of either additional safety
> requirements and/or traits.
>
> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
> ---
> drivers/gpu/drm/nova/driver.rs | 5 +++++
> drivers/gpu/drm/tyr/driver.rs | 5 +++++
> rust/kernel/drm/device.rs | 6 +++++-
> rust/kernel/drm/driver.rs | 17 ++++++++++++++++-
> 4 files changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nova/driver.rs b/drivers/gpu/drm/nova/driver.rs
> index 2246d8e104e0..247a05f7b3a7 100644
> --- a/drivers/gpu/drm/nova/driver.rs
> +++ b/drivers/gpu/drm/nova/driver.rs
> @@ -69,3 +69,8 @@ impl drm::Driver for NovaDriver {
> (NOVA_GEM_INFO, drm_nova_gem_info, ioctl::AUTH | ioctl::RENDER_ALLOW, File::gem_info),
> }
> }
> +
> +// SAFETY: This trait requires implementers to observe the safety requirements
> +// of each enabled feature. There are no features enabled, so this is safe by
> +// definition.
> +unsafe impl drm::driver::DriverFeatures for NovaDriver {}
> diff --git a/drivers/gpu/drm/tyr/driver.rs b/drivers/gpu/drm/tyr/driver.rs
> index 0389c558c036..ec2aa30515a1 100644
> --- a/drivers/gpu/drm/tyr/driver.rs
> +++ b/drivers/gpu/drm/tyr/driver.rs
> @@ -191,6 +191,11 @@ impl drm::Driver for TyrDriver {
> }
> }
>
> +// SAFETY: This trait requires implementers to observe the safety requirements
> +// of each enabled feature. There are no features enabled, so this is safe by
> +// definition.
> +unsafe impl drm::driver::DriverFeatures for TyrDriver {}
> +
> #[pin_data]
> struct Clocks {
> core: Clk,
> diff --git a/rust/kernel/drm/device.rs b/rust/kernel/drm/device.rs
> index 3ce8f62a0056..cfc2f34e8cc2 100644
> --- a/rust/kernel/drm/device.rs
> +++ b/rust/kernel/drm/device.rs
> @@ -61,6 +61,10 @@ pub struct Device<T: drm::Driver> {
> }
>
> impl<T: drm::Driver> Device<T> {
> + const fn compute_features() -> u32 {
> + drm::driver::FEAT_GEM
> + }
> +
> const VTABLE: bindings::drm_driver = drm_legacy_fields! {
> load: None,
> open: Some(drm::File::<T::File>::open_callback),
> @@ -86,7 +90,7 @@ impl<T: drm::Driver> Device<T> {
> name: crate::str::as_char_ptr_in_const_context(T::INFO.name).cast_mut(),
> desc: crate::str::as_char_ptr_in_const_context(T::INFO.desc).cast_mut(),
>
> - driver_features: drm::driver::FEAT_GEM,
> + driver_features: Self::compute_features(),
> ioctls: T::IOCTLS.as_ptr(),
> num_ioctls: T::IOCTLS.len() as i32,
> fops: &Self::GEM_FOPS,
> diff --git a/rust/kernel/drm/driver.rs b/rust/kernel/drm/driver.rs
> index f30ee4c6245c..fdfd083ba2b6 100644
> --- a/rust/kernel/drm/driver.rs
> +++ b/rust/kernel/drm/driver.rs
> @@ -98,7 +98,7 @@ pub trait AllocImpl: super::private::Sealed + drm::gem::IntoGEMObject {
> /// This trait must be implemented by drivers in order to create a `struct drm_device` and `struct
> /// drm_driver` to be registered in the DRM subsystem.
> #[vtable]
> -pub trait Driver {
> +pub trait Driver: DriverFeatures {
> /// Context data associated with the DRM driver
> type Data: Sync + Send;
>
> @@ -168,3 +168,18 @@ fn drop(&mut self) {
> unsafe { bindings::drm_dev_unregister(self.0.as_raw()) };
> }
> }
> +
> +/// Marker trait for drivers supporting specific features.
> +///
> +/// This trait is unsafe, and each feature might add its own safety
> +/// requirements. The safety requirements for this trait requires the caller to
> +/// comply with the safety requirements of each supported feature.
> +///
> +/// Features might also require additional trait implementations to be present.
> +/// These additional traits may also be unsafe.
> +///
> +/// # Safety
> +///
> +/// Drivers implementing this trait must ensure they comply with the safety
> +/// requirements of each supported feature.
> +pub unsafe trait DriverFeatures {}
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/2] rust: drm: add support for driver features
2026-01-21 17:31 ` Gary Guo
@ 2026-01-21 19:05 ` Daniel Almeida
2026-05-05 10:13 ` Laura Nao
1 sibling, 0 replies; 6+ messages in thread
From: Daniel Almeida @ 2026-01-21 19:05 UTC (permalink / raw)
To: Gary Guo
Cc: Danilo Krummrich, Alice Ryhl, David Airlie, Simona Vetter,
Miguel Ojeda, Boqun Feng, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, Boris Brezillon, nouveau,
dri-devel, linux-kernel, rust-for-linux
Hi Gary,
> On 21 Jan 2026, at 14:31, Gary Guo <gary@garyguo.net> wrote:
>
> On Mon Jan 19, 2026 at 11:34 PM GMT, Daniel Almeida wrote:
>> Add initial support for drm driver features via the DriverFeatures trait.
>> This trait is unsafe, requiring the implementer to comply with the safety
>> requirements of each feature individually if the feature is enabled.
>
> I think such unsafe requirement is quite vague and also very non-local.
>
> Maybe we can use a single trait (the `ModesetOps` that you described) to do
> this:
>
> Something like:
>
> pub unsafe trait ModesetOps<D> { ... }
>
> // Maybe the never type in the future...
> pub enum NoFeature {}
>
> impl<D> ModesetOps<D> for NoFeature {
> fn foo(&self, ...) { unimplemented!() }
> }
>
> impl Driver {
> /// Reference the modeset implementation (typically Self),
> /// or `NoFeature` to indicate that the feature is not implemented.
> type Modeset: ModesetOps<Self>;
Yeah, this looks better indeed. I assume we can have multiple features by
having multiple traits, right?
> }
>
> When building, you can use `TypeId` to check if it's actually implemented, and
> set bits in the feature flags automatically.
>
> Best,
> Gary
I assume we would enable FeatureFoo if typeid(Foo) != typeid(NoFeatureFoo)?
Where Foo is “type Foo: FooOps” in the Driver trait.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/2] rust: drm: add support for driver features
2026-01-21 17:31 ` Gary Guo
2026-01-21 19:05 ` Daniel Almeida
@ 2026-05-05 10:13 ` Laura Nao
1 sibling, 0 replies; 6+ messages in thread
From: Laura Nao @ 2026-05-05 10:13 UTC (permalink / raw)
To: gary
Cc: a.hindborg, airlied, aliceryhl, bjorn3_gh, boqun.feng,
boris.brezillon, dakr, daniel.almeida, dri-devel, linux-kernel,
lossin, nouveau, ojeda, rust-for-linux, simona, tmgross
Hi Gary,
I just submitted a v2 [1] with DRIVER_RENDER modeled as a single
constant bool flag, as using a trait for this specific feature seemed
unnecessary.
This doesn't prevent us from modeling other features such as
FEAT_MODESET differently later, possibly with a trait and a constant
type that can only be constructed when the relevant trait is
implemented.
One thing probably worth noting about your previous suggestion, in case
it's useful for future feature implementations:
> On 21 Jan 2026, at 14:31, Gary Guo <gary@garyguo.net> wrote:
>
> When building, you can use `TypeId` to check if it's actually implemented, and
> set bits in the feature flags automatically.
>
Taking FEAT_MODESET as example, I believe this would translate to:
const fn compute_features() -> u32 {
let mut features = drm::driver::FEAT_GEM;
if TypeId::of::<T::Modeset>() != TypeId::of::<drm::driver::NoFeature>() {
features |= drm::driver::FEAT_MODESET;
}
features
}
However, this results in a compiler error as PartialEq is not yet
const-stable:
error[E0658]: cannot call conditionally-const operator in constant functions
--> rust/kernel/drm/device.rs:87:12
|
87 | if TypeId::of::<T::Render>() != TypeId::of::<drm::driver::NoFeature>() {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: calls in constant functions are limited to constant functions, tuple structs and tuple variants
= note: see issue #143874 <https://github.com/rust-lang/rust/issues/143874> for more information
= help: add `#![feature(const_trait_impl)]` to the crate attributes to enable
= note: this compiler was built on 2026-03-25; consider upgrading it if it is out of date
error: `PartialEq` is not yet stable as a const trait
--> rust/kernel/drm/device.rs:87:12
|
87 | if TypeId::of::<T::Render>() != TypeId::of::<drm::driver::NoFeature>() {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
help: add `#![feature(const_cmp)]` to the crate attributes to enable
--> rust/kernel/lib.rs:68:1
|
68 + #![feature(const_cmp)]
|
error: aborting due to 2 previous errors
As TypeId comparison is currently unstable, I think a different approach
would be needed if this pattern is adopted for other features.
Best,
Laura
[1] v2: https://lore.kernel.org/all/20260505092304.108262-1-laura.nao@collabora.com/
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-05-05 10:13 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-01-19 23:34 [PATCH 0/2] DRM 'feature' support for DRM drivers Daniel Almeida
2026-01-19 23:34 ` [PATCH 1/2] rust: drm: add support for driver features Daniel Almeida
2026-01-21 17:31 ` Gary Guo
2026-01-21 19:05 ` Daniel Almeida
2026-05-05 10:13 ` Laura Nao
2026-01-19 23:34 ` [PATCH 2/2] rust: drm: add FeatureRender Daniel Almeida
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox