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: <ZpFMmAEdqo1dhj0s@cassiopeiae>
Date: Fri, 12 Jul 2024 17:32:40 +0200
From: Danilo Krummrich <dakr@...hat.com>
To: Daniel Almeida <daniel.almeida@...labora.com>
Cc: Steven Price <steven.price@....com>,
	Wedson Almeida Filho <wedsonaf@...il.com>, ojeda@...nel.org,
	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

On Fri, Jul 12, 2024 at 12:13:15PM -0300, Daniel Almeida wrote:
> 
> 
> > On 12 Jul 2024, at 11:53, Danilo Krummrich <dakr@...hat.com> wrote:
> > 
> > You could also just define those structures in a C header directly and use it
> > from Rust, can't you?
> > 
> 
> 
> Sure, I am open to any approach here. Although this looks a bit reversed to me.
> 
> i.e.: why should I declare these structs in a separate language and file, and then use them in Rust through bindgen? Sounds clunky.

The kernel exposes the uAPI as C header files. You just choose to do the
implementation in the kernel in Rust.

Hence, I'd argue that the uAPI header is the actual source. So, we should
generate stuff from those headers and not the other way around I think.

> 
> Right now, they are declared right next to where they are used in the code, i.e.: in the same Rust file. And so long as they’re #[repr(C)] we know that an equivalent C version can generated by cbindgen.
> 

I'm not sure whether it's a good idea to generate uAPI header files in general.

How do we ensure that the generated header file are useful for userspace in
terms of readability and documentation?

How do we (easily) verify that changes in the Rust code don't break the uAPI by
due to leading to changes in the generated header files?

Do we have guarantees that future releases of cbindgen can't break anything?


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ