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

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: <CANiq72mpYjdhq6yZFBmy8zEo7Cjhh-WjOFc4TfKMZh+w4Fu5WA@mail.gmail.com>
Date:   Wed, 11 May 2022 15:49:50 +0200
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     Jonathan Corbet <corbet@....net>
Cc:     Miguel Ojeda <ojeda@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        rust-for-linux <rust-for-linux@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Alex Gaynor <alex.gaynor@...il.com>,
        Finn Behrens <me@...enk.de>,
        Adam Bratschi-Kaye <ark.email@...il.com>,
        Wedson Almeida Filho <wedsonaf@...gle.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Sven Van Asbroeck <thesven73@...il.com>,
        Wu XiangCheng <bobwxc@...il.cn>, Gary Guo <gary@...yguo.net>,
        Boris-Chengbiao Zhou <bobo1239@....de>,
        Yuki Okushi <jtitor@...6.org>, Wei Liu <wei.liu@...nel.org>,
        Daniel Xu <dxu@...uu.xyz>, Julian Merkle <me@...erkle.de>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>
Subject: Re: [PATCH v6 18/23] docs: add Rust documentation

On Tue, May 10, 2022 at 12:32 AM Jonathan Corbet <corbet@....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