linux-kernel - Re: Rust kernel policy

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: <Z7T5_WGX_VXBby9k@boqun-archlinux>
Date: Tue, 18 Feb 2025 13:22:05 -0800
From: Boqun Feng <boqun.feng@...il.com>
To: Jarkko Sakkinen <jarkko@...nel.org>
Cc: Christoph Hellwig <hch@...radead.org>,
	Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
	rust-for-linux <rust-for-linux@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	David Airlie <airlied@...il.com>, linux-kernel@...r.kernel.org,
	ksummit@...ts.linux.dev
Subject: Re: Rust kernel policy

On Tue, Feb 18, 2025 at 08:08:42PM +0200, Jarkko Sakkinen wrote:
> On Tue, 2025-02-18 at 18:39 +0200, Jarkko Sakkinen wrote:
> > On Tue, 2025-02-18 at 18:35 +0200, Jarkko Sakkinen wrote:
> > > On Tue, 2025-02-18 at 08:08 -0800, Christoph Hellwig wrote:
> > > > On Sun, Feb 09, 2025 at 09:56:35PM +0100, Miguel Ojeda wrote:
> > > > > Hi all,
> > > > > 
> > > > > Given the discussions in the last days, I decided to publish
> > > > > this
> > > > > page
> > > > > with what our understanding is:
> > > > > 
> > > > >     https://rust-for-linux.com/rust-kernel-policy
> > > > > 
> > > > > I hope it helps to clarify things. I intend to keep it updated
> > > > > as
> > > > > needed.
> > > > 
> > > > I don't think having a web page in any form is useful.  If you
> > > > want
> > > > it
> > > > to be valid it has to be in the kernel tree and widely agreed on.
> > > 
> > > I'd emphasize here that MUST be in the kernel tree. Otherwise, it
> > > by
> > > the
> > > process can be safely ignored without a second thought.
> > > 
> > > Doing random pointless annoucements is LF thing, not korg thing ;-)
> > 
> > ... underlining that it would be also welcome take. But like that
> > the policy plain sucks tbh.
> 
> One take: Documentation/SubmittingRustPatches with things to take into
> consideration when submitting Rust patches.
> 

Hmm... anything particular makes Rust patches different that you want to
add in that document?

> "policy" is something is more appropriate word of choice to something
> like how to behave (e.g. CoC).
> 
> Here some pratical recipes on how to deal with Rust patches would bring
> the maximum amount of value.
> 
> E.g. here's one observation from DMA patches: there was no test payload.
> AFAIK that alone should lead into an automatic and non-opionated NAK. I
> know this because I thought "I'll help instead of debating and at least
> test the patches" only to realize that there is total zero callers.
> 

FWIW, usually Rust code has doc tests allowing you to run it with kunit,
see:

	https://docs.kernel.org/rust/testing.html	

, I took a look at the DMA patches, there is one doc test, but
unfortunately it's only a function definition, i.e. it won't run these
DMA bindings.

I agree that test payload should be provided, there must be something
mentioning this in Documentation/process/submitting-patches.rst already?

Regards,
Boqun

> Neither I could find a document which would explain to me why this is
> fine.
> 
> BR, Jarkko
>