Re: Rust kernel policy

Jarkko Sakkinen
2025-02-18T18:08:47Z

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