linux-kernel - Re: [WIP RFC v2 05/35] rust: drm/kms: Add bindings for 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z1lQnhKmH39C7Erl@phenom.ffwll.local>
Date: Wed, 11 Dec 2024 09:43:10 +0100
From: Simona Vetter <simona.vetter@...ll.ch>
To: Lyude Paul <lyude@...hat.com>
Cc: Daniel Almeida <daniel.almeida@...labora.com>,
	dri-devel@...ts.freedesktop.org, rust-for-linux@...r.kernel.org,
	Asahi Lina <lina@...hilina.net>, Danilo Krummrich <dakr@...nel.org>,
	mcanal@...lia.com, airlied@...hat.com, zhiw@...dia.com,
	cjia@...dia.com, jhubbard@...dia.com,
	Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>,
	Wedson Almeida Filho <wedsonaf@...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@...sung.com>,
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
	open list <linux-kernel@...r.kernel.org>
Subject: Re: [WIP RFC v2 05/35] rust: drm/kms: Add bindings for drm_connector

On Tue, Dec 10, 2024 at 06:41:52PM -0500, Lyude Paul wrote:
> On Tue, 2024-11-26 at 18:25 -0300, Daniel Almeida wrote:
> > Hi Lyude,
> > 
> > > On 30 Sep 2024, at 20:09, Lyude Paul <lyude@...hat.com> wrote:
> > > 
> > > +
> > > +impl<T: DriverConnector> Connector<T> {
> > > +    /// Construct a new [`Connector`].
> > > +    ///
> > > +    /// A driver may use this to create new [`Connector`] objects.
> > > +    ///
> > > +    /// TODO: Add a way to handle creating connectors after device registration. Also, that's why we
> > > +    /// don't ask for a UnregisteredKms device here.
> > 
> > Can you elaborate? We can try to help if you describe this a bit better :)
> 
> oh - totally forgot to respond to this!
> 
> So: out of all of the mode objects, Connectors are a bit special. They can
> actually be created and destroyed after registration (hence why they have a
> refcount). This is not terribly difficult to handle before registration, the
> complication comes after registration - where we'll likely need to split
> Connector into two different types:
> 
> UnregisteredConnector
> 
> Connector
> 
> Where you have to sacrifice the UnregisteredConnector to get to the Connector
> object. I don't think this will actually be too difficult to implement, I just
> didn't get around to it yet because there were so many other open questions I
> had about the design here in general.

For connnnector lifetime fun please also see Imre's patches for fixing
some races around mst hotplug. At least on the C side I think we will
split connectors into dynamic and static ones, to be able to handle things
correctly. It's a bit a mess unfortuantely.
-Sima
-- 
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch