rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Carsten Haitzler <carsten.haitzler@foss.arm.com>
To: Steven Price <steven.price@arm.com>,
	Rob Herring <robh@kernel.org>,
	Boris Brezillon <boris.brezillon@collabora.com>,
	Daniel Almeida <daniel.almeida@collabora.com>
Cc: Wedson Almeida Filho <wedsonaf@gmail.com>,
	ojeda@kernel.org, Danilo Krummrich <dakr@redhat.com>,
	lyude@redhat.com, lina@asahilina.net, mcanal@igalia.com,
	airlied@gmail.com, rust-for-linux@vger.kernel.org,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] drm: panthor: add dev_coredumpv support
Date: Thu, 25 Jul 2024 12:42:44 +0100	[thread overview]
Message-ID: <68f0fdfc-8bc2-462d-9d0d-4d0ad41c6811@foss.arm.com> (raw)
In-Reply-To: <6b60a83d-8416-4cf8-b373-dc3c697c788a@arm.com>


>> We did discuss this, but I've come to the conclusion that's the wrong
>> approach. Converting is going to need to track kernel closely as there
>> are lots of dependencies with the various rust abstractions needed. If
>> we just copy over the C driver, that's an invitation to diverge and
>> accumulate technical debt. The advice to upstreaming things is never
>> go work on a fork for a couple of years and come back with a huge pile
>> of code to upstream. I don't think this situation is any different. If
>> there's a path to do it in small pieces, we should take it.
> 
> I'd be quite keen for the "fork" to live in the upstream kernel. My
> preference is for the two drivers to sit side-by-side. I'm not sure
> whether that's a common view though.

I agree that a panthor.rs should to exist side by side with the C for 
some time. I guess it's going to be in the order of a year or so (or 
maybe more) and not a few weeks, so keeping the C and Rust in sync will 
be important.

My take is that such drivers probably belong in non-mainline dev trees 
until they settle a bit, are at least fully functional and we're down to 
arguing finer details. Especially since the other Rust infra they depend 
on not mainline yet either.

Given that, my opinion is this patch probably needs to be originally in 
C then with a rust idiomatic port in the in-progress rust rewrite, or 
there needs to be a lot more effort to building the right panthor layers 
such as better register abstractions for example as part of this which 
certainly will raise the workload to get this in.

  parent reply	other threads:[~2024-07-25 11:42 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-10 22:50 [RFC PATCH] drm: panthor: add dev_coredumpv support Daniel Almeida
2024-07-11  0:01 ` Danilo Krummrich
2024-07-15  9:03   ` Daniel Vetter
2024-07-15 17:05     ` Daniel Almeida
2024-07-16  9:25       ` Daniel Vetter
2024-07-25 19:35         ` Lyude Paul
2024-07-26 13:40           ` Daniel Vetter
2024-07-29 18:34             ` Lyude Paul
2024-07-30  8:29               ` Daniel Vetter
2024-07-11 16:57 ` Liviu Dudau
2024-07-11 18:40   ` Daniel Almeida
2024-07-12  9:46 ` Steven Price
2024-07-12 14:35   ` Daniel Almeida
2024-07-12 14:53     ` Danilo Krummrich
2024-07-12 15:13       ` Daniel Almeida
2024-07-12 15:32         ` Danilo Krummrich
2024-07-13  0:48           ` Dave Airlie
2024-07-13  1:00             ` Daniel Almeida
2024-07-13  8:17             ` Miguel Ojeda
2024-07-15  9:12     ` Steven Price
2024-07-23  9:44       ` Alice Ryhl
2024-07-23 16:06       ` Boris Brezillon
2024-07-23 17:23         ` Daniel Almeida
2024-07-24  8:59         ` Steven Price
2024-07-24 10:44           ` Boris Brezillon
2024-07-24 12:37             ` Steven Price
2024-07-24 13:15           ` Rob Herring
2024-07-24 13:54             ` Steven Price
2024-07-24 14:27               ` Daniel Almeida
2024-07-24 14:35                 ` Steven Price
2024-07-24 14:38               ` Miguel Ojeda
2024-07-25 11:42               ` Carsten Haitzler [this message]
2024-07-25 11:45         ` Carsten Haitzler
2024-07-23  9:53 ` Alice Ryhl
2024-07-23 13:41   ` Daniel Almeida
2024-07-23 13:45     ` Alice Ryhl

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=68f0fdfc-8bc2-462d-9d0d-4d0ad41c6811@foss.arm.com \
    --to=carsten.haitzler@foss.arm.com \
    --cc=airlied@gmail.com \
    --cc=boris.brezillon@collabora.com \
    --cc=dakr@redhat.com \
    --cc=daniel.almeida@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=lina@asahilina.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lyude@redhat.com \
    --cc=mcanal@igalia.com \
    --cc=ojeda@kernel.org \
    --cc=robh@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=steven.price@arm.com \
    --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;
as well as URLs for NNTP newsgroup(s).