From: Danilo Krummrich <dakr@redhat.com>
To: Fabien Parent <fabien.parent@linaro.org>
Cc: David Airlie <airlied@redhat.com>,
Greg KH <gregkh@linuxfoundation.org>,
rafael@kernel.org, ojeda@kernel.org, alex.gaynor@gmail.com,
wedsonaf@gmail.com, boqun.feng@gmail.com, gary@garyguo.net,
bjorn3_gh@protonmail.com, benno.lossin@proton.me,
a.hindborg@samsung.com, aliceryhl@google.com, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
rust-for-linux@vger.kernel.org, x86@kernel.org, lyude@redhat.com,
pstanner@redhat.com, ajanulgu@redhat.com,
Asahi Lina <lina@asahilina.net>
Subject: Re: [PATCH 4/8] rust: add driver abstraction
Date: Tue, 2 Apr 2024 15:51:02 +0200 [thread overview]
Message-ID: <ZgwNRmzUfO0hCqCm@polis> (raw)
In-Reply-To: <CAPFo5VLoYGq_OgC5dqcueTyymuSCsLpjasLZnKO1jpY6gV7s2g@mail.gmail.com>
Hi Fabien,
On Sun, Mar 31, 2024 at 12:17:15PM -0700, Fabien Parent wrote:
> [re-sending as plain text instead of HTML]
>
> On Mon, Mar 25, 2024 at 11:35 PM David Airlie <airlied@redhat.com> wrote:
> > > I don't mind 50 patch long series, those are fine as we can see how
> > > things are actually used.
> > >
> > > But for complex beasts like DRM drivers, perhaps people should stop and
> > > implement the tiny "easy" things first, with working users, to verify
> > > that it is all ok first before biting off the big ones.
> > >
> > > Like implement a "simple" bus, which means that you have to have the
> > > driver core bindings all working properly and correctly. Once that is
> > > done and merged then move to the next thing (i.e. a more complex bus
> > > like PCI or USB or platform).
> >
> > This is just reintroducing the chicken/egg problem. Implementing a
> > "simple" bus usually means implementing a "simple" driver for that
> > bus. Implementing a simple driver for that bus often means
> > reimplementing an existing driver that is already in the tree. The
> > "simple" bus driver gets pushed back on because it's duplicating
> > functionality that is already in the tree and nobody reviews anything
> > and we re-enter the deadlock cycle. We are actively trying to break
> > the cycle and get stuff upstream so this can be properly explored
> > rather than 20 independent trees carrying out of date patchsets to get
> > anywhere.
>
> I've been working on a new driver [0] (not a reimplementation of an
> existing one) that uses I2C. I2C is a "simple bus" and the amount of
> commits is quite reasonable, maybe this would fit better as a consumer
> of the device driver abstractions for upstreaming purposes?
I don't know if it fits better, but I think it works just as well.
The whole reason Dave agreed to take a stub Nova driver [1] is to keep things
simple enough to get the corresponding *basic* device / driver, PCI and DRM
bindings upstream. I don't think the initial PCI device bindings turn out to be
more complex than any other subsystem device bindings in terms of delivering the
required context to review things.
Nevertheless, the I2C driver might indeed have even less dependencies overall.
Besides that, any additional initial user is desirable to get more evidence of
correctness.
So, maybe we just want to go with both as context for the review process?
> The work is happening here [1] and is fully functional. Right now the
> branch is not based on this series but based on the device
> abstractions from the old `rust` branch + a few others picked-up from
> the `asahi` tree and the mailing list.
That's what staging/rust-device [2] is basically based on as well.
The idea was to come up with topic branches for infrastructure that is in the
process of going upstream or in preparation for entering this process (hence the
"staging" prefix), such that we have a common baseline for drivers that are in
development. Instead of having every driver tree carrying those things in
several different versions missing out on potential improvements a driver tree
adds to them.
You are very welcome to base your project on this branch as well and provide
feedback and / or improvements, if you like to.
- Danilo
[1] https://lore.kernel.org/dri-devel/Zfsj0_tb-0-tNrJy@cassiopeiae/T/#u
[2] https://github.com/Rust-for-Linux/linux/tree/staging/rust-device
>
> [0] https://github.com/Fabo/linux/commit/64a35401316aa9d77490eadb7c4bb731c7901f69
> [1] https://github.com/Fabo/linux/commits/fparent/rust-ncv6336/
>
> Fabien
>
next prev parent reply other threads:[~2024-04-02 13:51 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-25 17:49 [PATCH 0/8] [RFC] Rust device / driver abstractions Danilo Krummrich
2024-03-25 17:49 ` [PATCH 1/8] arch: x86: tools: increase symbol name size Danilo Krummrich
2024-03-25 17:53 ` Miguel Ojeda
2024-03-25 18:01 ` Danilo Krummrich
2024-03-25 18:18 ` Miguel Ojeda
2024-03-25 17:49 ` [PATCH 2/8] rust: device: Add a minimal RawDevice trait Danilo Krummrich
2024-03-25 18:14 ` Greg KH
2024-03-25 18:22 ` Miguel Ojeda
2024-03-26 22:38 ` Danilo Krummrich
2024-03-27 5:25 ` Greg KH
2024-03-27 11:39 ` Danilo Krummrich
2024-03-25 17:49 ` [PATCH 3/8] rust: device: Add a stub abstraction for devices Danilo Krummrich
2024-03-25 17:58 ` Boqun Feng
2024-03-27 11:36 ` Danilo Krummrich
2024-03-25 18:14 ` Greg KH
2024-03-25 18:17 ` Greg KH
2024-03-26 16:01 ` Danilo Krummrich
2024-03-26 18:03 ` Greg KH
2024-03-26 19:03 ` Boqun Feng
2024-03-26 21:01 ` Danilo Krummrich
2024-03-27 1:38 ` Wedson Almeida Filho
2024-03-27 5:22 ` Greg KH
2024-03-27 9:05 ` Philipp Stanner
2024-03-27 9:13 ` Greg KH
2024-03-27 11:35 ` Danilo Krummrich
2024-03-25 17:49 ` [PATCH 4/8] rust: add driver abstraction Danilo Krummrich
2024-03-25 18:12 ` Greg KH
2024-03-25 18:30 ` Greg KH
2024-03-25 19:36 ` David Airlie
2024-03-26 5:37 ` Greg KH
2024-03-26 6:02 ` David Airlie
2024-03-26 6:14 ` Greg KH
2024-03-26 6:34 ` David Airlie
2024-03-31 19:17 ` Fabien Parent
2024-04-02 13:51 ` Danilo Krummrich [this message]
2024-03-28 10:41 ` Viresh Kumar
2024-03-25 17:49 ` [PATCH 5/8] rust: add rcu abstraction Danilo Krummrich
2024-03-25 17:49 ` [PATCH 6/8] rust: add revocable mutex Danilo Krummrich
2024-03-25 18:22 ` Greg KH
2024-03-26 18:13 ` Danilo Krummrich
2024-03-26 18:17 ` Greg KH
2024-03-26 21:32 ` Danilo Krummrich
2024-03-25 17:49 ` [PATCH 7/8] rust: add revocable objects Danilo Krummrich
2024-03-25 18:21 ` Greg KH
2024-03-26 17:07 ` Danilo Krummrich
2024-03-26 18:16 ` Greg KH
2024-03-26 21:48 ` Danilo Krummrich
2024-03-27 1:31 ` Wedson Almeida Filho
2024-03-25 17:49 ` [PATCH 8/8] rust: add device::Data Danilo Krummrich
2024-03-25 18:21 ` Greg KH
2024-03-26 16:54 ` Danilo Krummrich
2024-03-26 18:12 ` Greg KH
2024-03-26 22:24 ` 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=ZgwNRmzUfO0hCqCm@polis \
--to=dakr@redhat.com \
--cc=a.hindborg@samsung.com \
--cc=airlied@redhat.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=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=fabien.parent@linaro.org \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=lina@asahilina.net \
--cc=lyude@redhat.com \
--cc=mingo@redhat.com \
--cc=ojeda@kernel.org \
--cc=pstanner@redhat.com \
--cc=rafael@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=wedsonaf@gmail.com \
--cc=x86@kernel.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).