Re: Rust kernel policy

[Boqun Feng <boqun.feng@gmail.com>]

On Wed, Feb 19, 2025 at 08:20:31AM +0200, Jarkko Sakkinen wrote:
> On Tue, 2025-02-18 at 13:22 -0800, Boqun Feng wrote:
> > FWIW, usually Rust code has doc tests allowing you to run it with
> > kunit,
> > see:
> > 
> > 	https://docs.kernel.org/rust/testing.html	
> 
> I know this document and this was what I used to compile DMA patches.
> Then I ended up into "no test, no go" state :-)
> 

Good to know, thanks for giving it a try!

> I put this is way. If that is enough, or perhaps combined with
> submitting-patches.rst, why this email thread exists?
> 
> > 
> > , 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?
> 
> Partly yes. This what was exactly what I was wondering when I read
> through the thread, i.e. why no one is speaking about tests :-)
> 

In my opinion, about testing, code style check, commit log, etc. Rust
patches should be the same as C patches, at least during my reviews, I
treat both the same. Therefore I wasn't clear about why you want
additional information about Rust patch only, or what you exactly
proposed to add into kernel documentation for Rust patch.

The policy documentation in this email clarifies some higher level
stuffs than patch submission and development, such as "How is Rust
introduced in a subsystem", this is for developers' information maybe
even before development work. And I agree with Miguel, if we want this
information in-tree, we can certainly do that.

Hope this can answer your question?

> > 
> > Regards,
> > Boqun
> 
> Thanks for responding, definitely not picking a fight here. I

Oh, I didn't think it was picking a fight, just not sure what you
exactly proposed, hence I had to ask.

> actually just wanted to help, and doing kernel QA is the best
> possible way to take the first baby steps on a new subsystem,

Agreed! Appreciate the help.

Regards,
Boqun

> and sort of area where I'm professional already as a kernel
> maintainer.
> 
> BR, Jarkko