linux-kernel - Re: [RFC v3 05/33] rust: drm/kms: Add drm

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-prev] [day] [month] [year] [list]

Message-ID: <20250314-tunneling-brown-hornet-a6c584@houat>
Date: Fri, 14 Mar 2025 12:37:38 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Lyude Paul <lyude@...hat.com>
Cc: dri-devel@...ts.freedesktop.org, rust-for-linux@...r.kernel.org, 
	Danilo Krummrich <dakr@...nel.org>, mcanal@...lia.com, Alice Ryhl <aliceryhl@...gle.com>, 
	Simona Vetter <sima@...ll.ch>, Daniel Almeida <daniel.almeida@...labora.com>, 
	Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, 
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, Benno Lossin <benno.lossin@...ton.me>, 
	Andreas Hindborg <a.hindborg@...nel.org>, Trevor Gross <tmgross@...ch.edu>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Asahi Lina <lina@...hilina.net>, 
	Wedson Almeida Filho <wedsonaf@...il.com>, open list <linux-kernel@...r.kernel.org>
Subject: Re: [RFC v3 05/33] rust: drm/kms: Add drm_plane bindings

On Wed, Mar 05, 2025 at 05:59:21PM -0500, Lyude Paul wrote:
> The next step is adding a set of basic bindings to create a plane, which
> has to happen before we can create a CRTC (since we need to be able to at
> least specify a primary plane for a CRTC upon creation). This mostly
> follows the same general pattern as connectors (AsRawPlane,
> AsRawPlaneState, etc.).
> 
> There is one major difference with planes vs. other types of atomic mode
> objects: drm_plane_state isn't the only base plane struct used in DRM
> drivers, as some drivers will use helpers like drm_shadow_plane_state which
> have a drm_plane_state embedded within them.

It's one of the things where I also think you could have broken down the
patch some more. drm_shadow_plane_state, while useful, is not central
and could be handled later on. Both would ease the review, and we could
merge the "central" plane support without it if we disagree only on that
part for example.


> Since we'll eventually be adding bindings for shadow planes, we introduce a
> PlaneStateHelper trait - which represents any data type which can be used
> as the main wrapping structure around a drm_plane_state - and we implement
> this trait for PlaneState<T>. This trait can be used in our C callbacks to
> allow for drivers to use different wrapping structures without needing to
> implement a separate set of FFI callbacks for each type. Currently planes
> are the only type I'm aware of which do this.

And I don't think it's any different to any other driver structure. It
looks like most of the users except two don't have any additional data
so can't we do something like

struct ShadowPlaneState<T: Default> {
	...,

	data: T,
}

And just put that into PlaneState just like any other driver?

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)