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: <e63089e15c6f4d19e77d2920d576e0134d8b7aa7.camel@kernel.org>
Date: Tue, 18 Feb 2025 20:08:42 +0200
From: Jarkko Sakkinen <jarkko@...nel.org>
To: Christoph Hellwig <hch@...radead.org>, Miguel Ojeda
	 <miguel.ojeda.sandonis@...il.com>
Cc: 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, 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.

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

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

BR, Jarkko