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: <20240723180642.73502856@collabora.com>
Date: Tue, 23 Jul 2024 18:06:42 +0200
From: Boris Brezillon <boris.brezillon@...labora.com>
To: Steven Price <steven.price@....com>
Cc: Daniel Almeida <daniel.almeida@...labora.com>, Wedson Almeida Filho
 <wedsonaf@...il.com>, ojeda@...nel.org, Danilo Krummrich <dakr@...hat.com>,
 lyude@...hat.com, robh@...nel.org, 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

Hi Steve,

On Mon, 15 Jul 2024 10:12:16 +0100
Steven Price <steven.price@....com> wrote:

> I note it also shows that the "panthor_regs.rs" would ideally be shared.
> For arm64 we have been moving to generating system register descriptions
> from a text source (see arch/arm64/tools/sysreg) - I'm wondering whether
> something similar is needed for Panthor to generate both C and Rust
> headers? Although perhaps that's overkill, sysregs are certainly
> somewhat more complex.

Just had a long discussion with Daniel regarding this panthor_regs.rs
auto-generation, and, while I agree this is something we'd rather do if
we intend to maintain the C and rust code base forever, I'm not
entirely convinced this is super useful here because:

1. the C code base is meant to be entirely replaced by a rust driver.
Of course, that's not going to happen overnight, so maybe it'd be worth
having this autogen script but...

2. the set of register and register fields seems to be pretty stable.
We might have a few things to update to support v11, v12, etc, but it
doesn't look like the layout will suddenly become completely different.

3. the number of registers and fields is somewhat reasonable, which
means we should be able to catch mistakes during review. And in case
one slip through, it's not the end of the world either because this
stays internal to the kernel driver. We'll either figure it out when
rust-ifying panthor components, or that simply means the register is
not used and the mistake is harmless until the register starts being
used

4. we're still unclear on how GPU registers should be exposed in rust,
so any script we develop is likely to require heavy changes every time
we change our mind

For all these reasons, I think I'd prefer to have Daniel focus on a
proper rust abstraction to expose GPU registers and fields the rust-way,
rather than have him spend days/weeks on a script that is likely to be
used a couple times (if not less) before the driver is entirely
rewritten in rust. I guess the only interesting aspect remaining after
the conversion is done is conciseness of register definitions if we
were using some sort of descriptive format that gets converted to rust
code, but it comes at the cost of maintaining this script. I'd probably
have a completely different opinion if the Mali register layout was a
moving target, but it doesn't seem to be the case.

FYI, Daniel has a python script parsing panthor_regs.h and generating
panthor_regs.rs out of it which he can share if you're interested.

Regards,

Boris