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 <[email protected]> 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/[email protected]/
