linux-kernel - Re: [RFC PATCH] drm: panthor: add dev

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: <68f0fdfc-8bc2-462d-9d0d-4d0ad41c6811@foss.arm.com>
Date: Thu, 25 Jul 2024 12:42:44 +0100
From: Carsten Haitzler <carsten.haitzler@...s.arm.com>
To: Steven Price <steven.price@....com>, Rob Herring <robh@...nel.org>,
 Boris Brezillon <boris.brezillon@...labora.com>,
 Daniel Almeida <daniel.almeida@...labora.com>
Cc: Wedson Almeida Filho <wedsonaf@...il.com>, ojeda@...nel.org,
 Danilo Krummrich <dakr@...hat.com>, lyude@...hat.com, lina@...hilina.net,
 mcanal@...lia.com, airlied@...il.com, rust-for-linux@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] drm: panthor: add dev_coredumpv support

>> 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.