From: Danilo Krummrich <dakr@kernel.org>
To: Lyude Paul <lyude@redhat.com>
Cc: airlied@gmail.com, simona@ffwll.ch,
maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, acurrid@nvidia.com, lina@asahilina.net,
daniel.almeida@collabora.com, j@jannau.net, ojeda@kernel.org,
alex.gaynor@gmail.com, boqun.feng@gmail.com, gary@garyguo.net,
bjorn3_gh@protonmail.com, benno.lossin@proton.me,
a.hindborg@kernel.org, aliceryhl@google.com, tmgross@umich.edu,
dri-devel@lists.freedesktop.org, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH 3/8] rust: drm: add driver abstractions
Date: Fri, 28 Mar 2025 23:46:12 +0100 [thread overview]
Message-ID: <Z-cmtEZzILsLVpu9@pollux> (raw)
In-Reply-To: <43ad9fdcc62897bd0a78689020a8dd291b045ce4.camel@redhat.com>
On Fri, Mar 28, 2025 at 06:00:11PM -0400, Lyude Paul wrote:
> On Wed, 2025-03-26 at 00:54 +0100, Danilo Krummrich wrote:
> > diff --git a/rust/kernel/drm/driver.rs b/rust/kernel/drm/driver.rs
> > new file mode 100644
> > index 000000000000..1ac770482ae0
> > --- /dev/null
> > +++ b/rust/kernel/drm/driver.rs
> > @@ -0,0 +1,143 @@
> > +// SPDX-License-Identifier: GPL-2.0 OR MIT
> > +
> > +//! DRM driver core.
> > +//!
> > +//! C header: [`include/linux/drm/drm_drv.h`](srctree/include/linux/drm/drm_drv.h)
> > +
> > +use crate::{bindings, drm, str::CStr};
> > +use macros::vtable;
> > +
> > +/// Driver use the GEM memory manager. This should be set for all modern drivers.
> > +pub const FEAT_GEM: u32 = bindings::drm_driver_feature_DRIVER_GEM;
> > +/// Driver supports mode setting interfaces (KMS).
> > +pub const FEAT_MODESET: u32 = bindings::drm_driver_feature_DRIVER_MODESET;
> > +/// Driver supports dedicated render nodes.
> > +pub const FEAT_RENDER: u32 = bindings::drm_driver_feature_DRIVER_RENDER;
> > +/// Driver supports the full atomic modesetting userspace API.
> > +///
> > +/// Drivers which only use atomic internally, but do not support the full userspace API (e.g. not
> > +/// all properties converted to atomic, or multi-plane updates are not guaranteed to be tear-free)
> > +/// should not set this flag.
> > +pub const FEAT_ATOMIC: u32 = bindings::drm_driver_feature_DRIVER_ATOMIC;
> > +/// Driver supports DRM sync objects for explicit synchronization of command submission.
> > +pub const FEAT_SYNCOBJ: u32 = bindings::drm_driver_feature_DRIVER_SYNCOBJ;
> > +/// Driver supports the timeline flavor of DRM sync objects for explicit synchronization of command
> > +/// submission.
> > +pub const FEAT_SYNCOBJ_TIMELINE: u32 = bindings::drm_driver_feature_DRIVER_SYNCOBJ_TIMELINE;
> > +/// Driver supports compute acceleration devices. This flag is mutually exclusive with `FEAT_RENDER`
> > +/// and `FEAT_MODESET`. Devices that support both graphics and compute acceleration should be
> > +/// handled by two drivers that are connected using auxiliary bus.
> > +pub const FEAT_COMPUTE_ACCEL: u32 = bindings::drm_driver_feature_DRIVER_COMPUTE_ACCEL;
> > +/// Driver supports user defined GPU VA bindings for GEM objects.
> > +pub const FEAT_GEM_GPUVA: u32 = bindings::drm_driver_feature_DRIVER_GEM_GPUVA;
> > +/// Driver supports and requires cursor hotspot information in the cursor plane (e.g. cursor plane
> > +/// has to actually track the mouse cursor and the clients are required to set hotspot in order for
> > +/// the cursor planes to work correctly).
> > +pub const FEAT_CURSOR_HOTSPOT: u32 = bindings::drm_driver_feature_DRIVER_CURSOR_HOTSPOT;
>
> IMHO I don't think that we should be exposing any of these constants, building
> the feature flag mask should honestly be abstracted away into the rust
> bindings as not doing so means it's very easy to break assumptions that could
> lead to unsoundness.
Yep, that was the plan, just forgot to make them crate private; on the other
hand I should probably drop them entirely for now.
- Danilo
next prev parent reply other threads:[~2025-03-28 22:46 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-25 23:54 [PATCH 0/8] DRM Rust abstractions Danilo Krummrich
2025-03-25 23:54 ` [PATCH 1/8] drm: drv: implement __drm_dev_alloc() Danilo Krummrich
2025-03-26 8:46 ` Maxime Ripard
2025-03-25 23:54 ` [PATCH 2/8] rust: drm: ioctl: Add DRM ioctl abstraction Danilo Krummrich
2025-03-25 23:54 ` [PATCH 3/8] rust: drm: add driver abstractions Danilo Krummrich
2025-03-26 9:05 ` Maxime Ripard
2025-03-28 22:00 ` Lyude Paul
2025-03-28 22:46 ` Danilo Krummrich [this message]
2025-03-25 23:54 ` [PATCH 4/8] rust: drm: add device abstraction Danilo Krummrich
2025-03-26 9:12 ` Maxime Ripard
2025-03-25 23:54 ` [PATCH 5/8] rust: drm: add DRM driver registration Danilo Krummrich
2025-03-26 9:24 ` Maxime Ripard
2025-03-26 10:46 ` Danilo Krummrich
2025-03-28 14:28 ` Maxime Ripard
2025-03-28 14:50 ` Danilo Krummrich
2025-04-10 9:23 ` Maxime Ripard
2025-03-25 23:54 ` [PATCH 6/8] rust: drm: file: Add File abstraction Danilo Krummrich
2025-03-28 14:42 ` Maxime Ripard
2025-03-25 23:54 ` [PATCH 7/8] rust: drm: gem: Add GEM object abstraction Danilo Krummrich
2025-03-25 23:54 ` [PATCH 8/8] MAINTAINERS: add DRM Rust source files to DRM DRIVERS Danilo Krummrich
2025-03-28 14:49 ` Maxime Ripard
2025-03-28 14:50 ` Danilo Krummrich
2025-04-08 16:29 ` [PATCH 0/8] DRM Rust abstractions Asahi Lina
2025-04-08 17:04 ` Danilo Krummrich
2025-04-08 18:06 ` Asahi Lina
2025-04-08 19:17 ` Danilo Krummrich
2025-04-09 7:49 ` Asahi Lina
2025-04-09 21:29 ` Dave Airlie
2025-04-10 4:33 ` Asahi Lina
2025-04-10 7:12 ` Asahi Lina
2025-04-10 10:23 ` Danilo Krummrich
2025-04-10 12:37 ` Asahi Lina
2025-04-10 13:33 ` Danilo Krummrich
2025-04-11 0:43 ` Dave Airlie
2025-04-11 6:53 ` Asahi Lina
2025-04-10 6:44 ` Simona Vetter
2025-04-10 8:14 ` Asahi Lina
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=Z-cmtEZzILsLVpu9@pollux \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=acurrid@nvidia.com \
--cc=airlied@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=daniel.almeida@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=j@jannau.net \
--cc=lina@asahilina.net \
--cc=lyude@redhat.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=tmgross@umich.edu \
--cc=tzimmermann@suse.de \
/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;
as well as URLs for NNTP newsgroup(s).