Re: [PATCH v2 2/2] gpu: nova-core: add initial documentation

[Danilo Krummrich]

On Wed, Feb 05, 2025 at 04:56:32PM +0200, Zhi Wang wrote:
> On Wed, 5 Feb 2025 15:13:12 +0100
> Miguel Ojeda <miguel.ojeda.sandonis@xxxxxxxxx> wrote:
> 
> > On Wed, Feb 5, 2025 at 2:57 PM Zhi Wang <zhiw@xxxxxxxxxx> wrote:
> > >
> > > It would be also helpful to make the process explicit. E.g. sharing your
> > > command lines used to checking the patches. So folks can align with the
> > > expected outcome, e.g. command line parameters.
> > 
> > These two guidelines (and generally the few others above) are intended
> > to apply to all Rust code in the kernel (i.e. not just `rust/`) --
> > their command lines are mentioned in `Documentation/rust/`. We could
> > add a note to make that clearer if that helps. So I would suggest
> > avoiding repetition here by referencing those.

Regarding the two, for me they read more like suggestions. The few others are
indeed pretty clearly documented in "general-information".

Gonna add references instead.

> > 
> > We also mention it in our "Subsystem Profile document" at
> > https://rust-for-linux.com/contributing#submit-checklist-addendum.
> 
> I think we can refer the links so that we don't need to explain the
> process in detail. I would prefer to have the exact command lines that
> maintainer are using in the doce. E.g. I was experiencing that folks using
> different params with checkpatch.pl, the outcome, .e.g. warnings are
> different. different spell-checks backend gives different errors.
> 
> It could be nice that we put the command lines explicitly so that folks
> would save some efforts on re-spin. It also saves maintainer's efforts.

Generally, I'm fine with adding the specific command that should be run before
sending patches in a single place for convenience in this document.

But maybe it makes sense to consider whether this could go into the generic Rust
documentation too?

> 
> Z.
> > 
> > > > +The availability of proper documentation is essential in terms of scalability,
> > > > +accessability for new contributors and maintainability of a project in general,
> > 
> > Typo: accessibility?
> > 
> > Cheers,
> > Miguel
> > 
>