Re: [PATCH v6 18/23] docs: add Rust documentation

Miguel Ojeda
2022-05-11T13:50:10Z

On Tue, May 10, 2022 at 12:32 AM Jonathan Corbet <corbet@lwn.net> wrote:
>
> Trying to take a closer look this time...
>
> I foresee merge conflicts, but so it goes. Trying to split this apart
> would not make a lot of sense.

Is there a big change coming to docs? (there are not conflicts in
linux-next within the docs). Or what do you mean?

> Please use normal tables rather than list-table; this kind of thing is
> really unreadable in the source form.

Will do!

> I foresee disagreements over coding style conventions in the
> future... I don't plan to be part of that conversation :)

Do you mean with the tool settings? I guess we may get some proposals
about tweaking them, yeah, but one reason to stick to the defaults is
to avoid that! :)

If you mean enforcing `rustfmt`, please see below.

> I will ask whether we want this, though. Why would anybody want to
> mass-reformat the entire body of kernel code? This seems like something
> that would generate an endless stream of "helpful" patches and a lot of
> churn.

So the idea is that, since everything is already formatted, the output
of this is empty (in mainline), like Gaelan/Josh mentioned. Thus
nobody should be sending any formatting patches since there is nothing
to change.

Now, for those developing and not running `rustfmt` automatically in
some way (e.g. in their editors), it can be useful to run it before
submitting the patches: the output should only show changes to
whatever you changed since everything else should be already
formatted.

Of course, as soon as others start submitting patches independently,
mistakes may slip through, but we are enforcing this in our CI (and it
could be done more centrally), so we should notice quickly.

There could be, of course, bugs in the tool; and there are a few
situations where the tool may not guarantee formatting stability, but
hopefully those are rare and small enough so that we can keep
enforcing this. I think it is worth trying.

Cheers,
Miguel