From: Danilo Krummrich <dakr@redhat.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: FUJITA Tomonori <fujita.tomonori@gmail.com>,
wedsonaf@gmail.com, maarten.lankhorst@linux.intel.com,
mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com,
daniel@ffwll.ch, ojeda@kernel.org, alex.gaynor@gmail.com,
boqun.feng@gmail.com, gary@garyguo.net, bjorn3_gh@protonmail.com,
benno.lossin@proton.me, a.hindborg@samsung.com,
aliceryhl@google.com, lina@asahilina.net, pstanner@redhat.com,
ajanulgu@redhat.com, lyude@redhat.com,
rust-for-linux@vger.kernel.org, dri-devel@lists.freedesktop.org,
nouveau@lists.freedesktop.org, mcgrof@kernel.org,
russ.weight@linux.dev
Subject: Re: [RFC PATCH 7/8] rust: add firmware abstractions
Date: Fri, 7 Jun 2024 19:55:49 +0200 [thread overview]
Message-ID: <ZmNJpQbTtFUPOkAJ@cassiopeiae> (raw)
In-Reply-To: <2024060745-palatable-dragging-32d1@gregkh>
On Fri, Jun 07, 2024 at 05:41:11PM +0200, Greg KH wrote:
> On Fri, Jun 07, 2024 at 03:33:39PM +0200, Danilo Krummrich wrote:
> > On Fri, Jun 07, 2024 at 02:36:50PM +0200, Greg KH wrote:
> > > Anyway, that's all hand-wavy right now, sorry, to get back to the point
> > > here, again, let's take this, which will allow the firmware bindings to
> > > be resubmitted and hopefully accepted, and we can move forward from
> > > there to "real" things like a USB or PCI or even platform device and
> > > driver binding stuff.
> >
> > In order to continue I propose to send out the following series:
> >
> > 1) minimal device and firmware abstractions only
>
> Sounds good.
Just a heads-up, I'll probably send this one quite a bit earlier than the other
two to make sure to unblock Fujita on their PHY driver.
>
> But after this, I don't want to take ANY driver core rust code that is
> not able to live in the "normal" part of the Linux kernel tree. It's
> just unsustainable to have it all in one directory sorry. If this
> deadline makes that kbuild work actually happen faster, all the more
> reason to have it. If that kbuild work is somehow stalled due to other
> issues, please let me know what that is.
>
> > 2) v2 of all other device / driver, devres and PCI driver abstractions
>
> I will be glad to review this.
Glad to hear that!
>
> > 3) v2 of basic DRM driver abstractions and Nova
>
> I love it how one of the most complex driver subsystems we have (drm) is
> attempting to be the "first real" driver use for the rust apis. Bold
> move :)
I'd argue that as one of the most complex driver subsystems we have a lot of
need for the advantages Rust provides to us. :)
>
> > The v2 series would contain static driver allocation (in case of DRM even const)
> > and quite a few more simplifications around `driver::Registration` and
> > `device::Data`.
> >
> > Does that make sense?
>
> Yes, but note, I'm going to probably push back on the "driver::" stuff.
That's OK, I'm happy to convince you of its usefulness. :)
> But will do so with more constructive criticism as I want this to work
> very much and I agree that I think we are both talking past each other
> in different ways. Mostly probably due to my total lack of Rust
> experience, my apologies, thanks for your patience with me for this.
Very much appreciated! Please don't hesitate to ask for more explanation on
certain things if they're unclear. I'm happy trying my best to provide useful
answers.
- Danilo
>
> thanks,
>
> greg k-h
>
next prev parent reply other threads:[~2024-06-07 17:55 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-20 17:20 [RFC PATCH 0/8] [RFC] DRM Rust abstractions and Nova Danilo Krummrich
2024-05-20 17:20 ` [RFC PATCH 1/8] rust: drm: ioctl: Add DRM ioctl abstraction Danilo Krummrich
2024-05-20 17:20 ` [RFC PATCH 2/8] rust: Add a Sealed trait Danilo Krummrich
2024-05-20 17:20 ` [RFC PATCH 3/8] rust: drm: Add Device and Driver abstractions Danilo Krummrich
2024-05-21 21:23 ` Rob Herring
2024-05-27 19:26 ` Danilo Krummrich
2024-06-09 5:15 ` Asahi Lina
2024-06-09 14:18 ` Danilo Krummrich
2024-06-11 15:46 ` Rob Herring
2024-05-20 17:20 ` [RFC PATCH 4/8] rust: drm: implement `AsRef` for DRM device Danilo Krummrich
2024-05-20 17:24 ` Danilo Krummrich
2024-05-20 17:24 ` [RFC PATCH 5/8] rust: drm: file: Add File abstraction Danilo Krummrich
2024-05-20 17:24 ` [RFC PATCH 6/8] rust: drm: gem: Add GEM object abstraction Danilo Krummrich
2024-06-06 15:26 ` Daniel Almeida
2024-05-20 17:24 ` [RFC PATCH 7/8] rust: add firmware abstractions Danilo Krummrich
2024-05-21 5:32 ` Zhi Wang
2024-05-27 19:18 ` Danilo Krummrich
2024-05-28 8:40 ` Zhi Wang
2024-05-28 10:17 ` FUJITA Tomonori
2024-05-28 10:45 ` Zhi Wang
2024-05-28 14:18 ` Danilo Krummrich
2024-05-28 21:20 ` Zhi Wang
2024-05-21 23:53 ` FUJITA Tomonori
2024-05-22 7:37 ` Philipp Stanner
2024-05-22 23:15 ` FUJITA Tomonori
2024-05-23 2:48 ` Boqun Feng
2024-05-27 19:22 ` Danilo Krummrich
2024-05-28 11:01 ` FUJITA Tomonori
2024-05-28 12:19 ` Danilo Krummrich
2024-05-28 12:45 ` Greg KH
2024-05-28 13:17 ` Danilo Krummrich
2024-05-29 0:28 ` FUJITA Tomonori
2024-05-29 19:57 ` Greg KH
2024-05-29 23:28 ` FUJITA Tomonori
2024-05-30 2:01 ` Danilo Krummrich
2024-05-30 4:24 ` FUJITA Tomonori
2024-05-30 6:47 ` Danilo Krummrich
2024-05-31 7:50 ` FUJITA Tomonori
2024-05-31 9:59 ` Danilo Krummrich
2024-06-07 12:11 ` FUJITA Tomonori
2024-06-07 12:36 ` Greg KH
2024-06-07 13:05 ` Danilo Krummrich
2024-06-07 13:33 ` Danilo Krummrich
2024-06-07 15:41 ` Greg KH
2024-06-07 17:55 ` Danilo Krummrich [this message]
2024-06-07 23:28 ` FUJITA Tomonori
2024-06-10 13:13 ` Danilo Krummrich
2024-06-07 12:43 ` Danilo Krummrich
2024-05-29 0:38 ` FUJITA Tomonori
2024-05-28 12:06 ` Danilo Krummrich
2024-05-20 17:24 ` [RFC PATCH 8/8] nova: add initial driver stub Danilo Krummrich
2024-05-20 17:30 ` Device / Driver and PCI Rust abstractions Danilo Krummrich
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=ZmNJpQbTtFUPOkAJ@cassiopeiae \
--to=dakr@redhat.com \
--cc=a.hindborg@samsung.com \
--cc=airlied@gmail.com \
--cc=ajanulgu@redhat.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@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=fujita.tomonori@gmail.com \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=lina@asahilina.net \
--cc=lyude@redhat.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mcgrof@kernel.org \
--cc=mripard@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--cc=pstanner@redhat.com \
--cc=russ.weight@linux.dev \
--cc=rust-for-linux@vger.kernel.org \
--cc=tzimmermann@suse.de \
--cc=wedsonaf@gmail.com \
/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