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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ