rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Akira Yokosawa <akiyks@gmail.com>
To: ojeda@kernel.org
Cc: alex.gaynor@gmail.com, ark.email@gmail.com, bobo1239@web.de,
	bobwxc@email.cn, corbet@lwn.net, dxu@dxuuu.xyz, gary@garyguo.net,
	gregkh@linuxfoundation.org, jarkko@kernel.org, jtitor@2k36.org,
	linux-doc@vger.kernel.org, linux-kbuild@vger.kernel.org,
	linux-kernel@vger.kernel.org, masahiroy@kernel.org,
	me@jvmerkle.de, me@kloenk.de, michal.lkml@markovi.net,
	mpe@ellerman.id.au, ndesaulniers@google.com,
	rust-for-linux@vger.kernel.org, thesven73@gmail.com,
	torvalds@linux-foundation.org, wedsonaf@google.com,
	wei.liu@kernel.org
Subject: Re: [PATCH v6 18/23] docs: add Rust documentation
Date: Mon, 9 May 2022 13:02:08 +0900	[thread overview]
Message-ID: <7e9c2e77-8b70-6e15-3f3d-905ab42b0fcd@gmail.com> (raw)
In-Reply-To: <20220507052451.12890-19-ojeda@kernel.org>

Hi Miguel,

On Sat,  7 May 2022 07:24:16 +0200,
Miguel Ojeda wrote:
> Most of the documentation for Rust is written within the source code
> itself, as it is idiomatic for Rust projects. This applies to both
> the shared infrastructure at `rust/` as well as any other Rust module
> (e.g. drivers) written across the kernel.
> 
> However, these documents contain general information that does not
> fit particularly well in the source code, like the Quick Start guide.
> 
> It also contains an asset (SVG logo) used for the `rustdoc` target
> and a few other small changes elsewhere in the documentation folder.
> 
> Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com>
> Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com>
> Co-developed-by: Finn Behrens <me@kloenk.de>
> Signed-off-by: Finn Behrens <me@kloenk.de>
> Co-developed-by: Adam Bratschi-Kaye <ark.email@gmail.com>
> Signed-off-by: Adam Bratschi-Kaye <ark.email@gmail.com>
> Co-developed-by: Wedson Almeida Filho <wedsonaf@google.com>
> Signed-off-by: Wedson Almeida Filho <wedsonaf@google.com>
> Co-developed-by: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Co-developed-by: Sven Van Asbroeck <thesven73@gmail.com>
> Signed-off-by: Sven Van Asbroeck <thesven73@gmail.com>
> Co-developed-by: Wu XiangCheng <bobwxc@email.cn>
> Signed-off-by: Wu XiangCheng <bobwxc@email.cn>
> Co-developed-by: Gary Guo <gary@garyguo.net>
> Signed-off-by: Gary Guo <gary@garyguo.net>
> Co-developed-by: Boris-Chengbiao Zhou <bobo1239@web.de>
> Signed-off-by: Boris-Chengbiao Zhou <bobo1239@web.de>
> Co-developed-by: Yuki Okushi <jtitor@2k36.org>
> Signed-off-by: Yuki Okushi <jtitor@2k36.org>
> Co-developed-by: Wei Liu <wei.liu@kernel.org>
> Signed-off-by: Wei Liu <wei.liu@kernel.org>
> Co-developed-by: Daniel Xu <dxu@dxuuu.xyz>
> Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
> Co-developed-by: Julian Merkle <me@jvmerkle.de>
> Signed-off-by: Julian Merkle <me@jvmerkle.de>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> ---
>  Documentation/doc-guide/kernel-doc.rst     |   3 +
>  Documentation/index.rst                    |   1 +
>  Documentation/kbuild/kbuild.rst            |  17 +
>  Documentation/kbuild/makefiles.rst         |  50 ++-
>  Documentation/process/changes.rst          |  41 +++
>  Documentation/rust/arch-support.rst        |  34 ++
>  Documentation/rust/coding-guidelines.rst   | 214 ++++++++++++
>  Documentation/rust/general-information.rst |  77 +++++
>  Documentation/rust/index.rst               |  20 ++
>  Documentation/rust/logo.svg                | 357 +++++++++++++++++++++
I think you agreed splitting SVG part into its own patch with
a proper copying info, etc.  Let me see...  So, here is the link:

https://lore.kernel.org/lkml/CANiq72mLtvWJ5peSTpYQ8AeLEskga6Pda8Q7Daysv2pfycnyxA@mail.gmail.com/

I might have missed v5 of this patch series.
That might be because v5's 15/20 was not accepted by linux-doc's
lore archive (maybe) due to its size despite it had Cc: linux-doc.
v6's 18/23 was also rejected.

>  Documentation/rust/quick-start.rst         | 230 +++++++++++++
>  11 files changed, 1040 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/rust/arch-support.rst
>  create mode 100644 Documentation/rust/coding-guidelines.rst
>  create mode 100644 Documentation/rust/general-information.rst
>  create mode 100644 Documentation/rust/index.rst
>  create mode 100644 Documentation/rust/logo.svg
>  create mode 100644 Documentation/rust/quick-start.rst

I have some alternative ideas for table formatting in ReST.

> diff --git a/Documentation/rust/arch-support.rst b/Documentation/rust/arch-support.rst
> new file mode 100644
> index 000000000000..482757a1f3d0
> --- /dev/null
> +++ b/Documentation/rust/arch-support.rst
> @@ -0,0 +1,34 @@
> +Arch Support
> +============
> +
> +Currently, the Rust compiler (``rustc``) uses LLVM for code generation,
> +which limits the supported architectures that can be targeted. In addition,
> +support for building the kernel with LLVM/Clang varies (please see
> +Documentation/kbuild/llvm.rst). This support is needed for ``bindgen``
> +which uses ``libclang``.
> +
> +Below is a general summary of architectures that currently work. Level of
> +support corresponds to ``S`` values in the ``MAINTAINERS`` file.
> +
> +.. list-table::
> +   :widths: 10 10 10
> +   :header-rows: 1
> +
> +   * - Architecture
> +     - Level of support
> +     - Constraints
> +   * - ``arm``
> +     - Maintained
> +     - ``armv6`` and compatible only, ``RUST_OPT_LEVEL >= 2``
> +   * - ``arm64``
> +     - Maintained
> +     - None
> +   * - ``powerpc``
> +     - Maintained
> +     - ``ppc64le`` only, ``RUST_OPT_LEVEL < 2`` requires ``CONFIG_THREAD_SHIFT=15``
> +   * - ``riscv``
> +     - Maintained
> +     - ``riscv64`` only
> +   * - ``x86``
> +     - Maintained
> +     - ``x86_64`` only

Excerpt from Section "list tables" in
Documentation/doc-guide/sphinx.rst:

> The list-table formats can be useful for tables that are not easily laid
> out in the usual Sphinx ASCII-art formats.  These formats are nearly
> impossible for readers of the plain-text documents to understand, though,
> and should be avoided in the absence of a strong justification for their
> use.

So here are a couple of alternative ways to represent the table

* ASCII-art format:

============ ================ ==========================================
Architecture Level of support Constraints
============ ================ ==========================================
``arm``      Maintained       ``armv6`` and compatible only,
                              ``RUST_OPT_LEVEL >= 2``
``arm64``    Maintained       None
``powerpc``  Maintained       ``ppc64le`` only, ``RUST_OPT_LEVEL < 2``
                              requires ``CONFIG_THREAD_SHIFT=15``
``riscv``    Maintained       ``riscv64`` only
``x86``      Maintained       ``x86_64`` only
============ ================ ==========================================

* Literal block format:

::

 Architecture  Level of support  Constraints
 ------------  ----------------  -------------------------------------
 arm           Maintained        armv6 and compatible only,
                                 RUST_OPT_LEVEL >= 2
 arm64         Maintained        None
 powerpc       Maintained        ppc64le only, RUST_OPT_LEVEL < 2
                                 requires CONFIG_THREAD_SHIFT=15
 riscv         Maintained        riscv64 only
 x86           Maintained        x86_64 only


"::" above the table marks the start of a literal block.
Indents are important for la iteral block to work.
A literal block ends at a line which has the same indent as
the preceding paragraph, in this case with no indent, or at
the end of file.

As you see, those inline-literal markers of ``xxxx``, which are
distracting when the .rst file is read as plain-text, are not
necessary in the literal-block approach.  And you can directly
tweak line breaks in the Constraints column in the final HTML
and PDF docs.

In my opinion, the literal-block approach should be the most
reasonable choice here. Of course its your call which one
to choose.

        Thanks, Akira

  parent reply	other threads:[~2022-05-09  4:09 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-07  5:23 [PATCH v6 00/23] Rust support Miguel Ojeda
2022-05-07  5:23 ` [PATCH v6 01/23] kallsyms: avoid hardcoding the buffer size Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 02/23] kallsyms: support "big" kernel symbols Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 03/23] kallsyms: increase maximum kernel symbol length to 512 Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 04/23] kunit: take `kunit_assert` as `const` Miguel Ojeda
2022-05-12 19:01   ` Brendan Higgins
2022-05-07  5:24 ` [PATCH v6 05/23] rust: add C helpers Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 06/23] rust: add `compiler_builtins` crate Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 08/23] rust: adapt `alloc` crate to the kernel Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 09/23] rust: add `build_error` crate Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 10/23] rust: add `macros` crate Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 13/23] rust: export generated symbols Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 14/23] vsprintf: add new `%pA` format specifier Miguel Ojeda
2022-05-07  8:19   ` Kees Cook
2022-05-07  9:35     ` Miguel Ojeda
2022-05-10  8:38   ` Petr Mladek
2022-05-10 10:45     ` Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 15/23] scripts: add `rustdoc_test_{builder,gen}.py` scripts Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 16/23] scripts: add `generate_rust_analyzer.py` scripts Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 17/23] scripts: decode_stacktrace: demangle Rust symbols Miguel Ojeda
2022-05-07  8:32   ` Kees Cook
2022-05-07 10:21     ` Miguel Ojeda
2022-05-07 17:09       ` Kees Cook
2022-05-07  5:24 ` [PATCH v6 19/23] Kbuild: add Rust support Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 20/23] samples: add Rust examples Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 21/23] MAINTAINERS: Rust Miguel Ojeda
2022-05-07  8:06   ` Kees Cook
2022-05-07  5:24 ` [PATCH v6 22/23] [RFC] drivers: gpio: PrimeCell PL061 in Rust Miguel Ojeda
     [not found] ` <20220507052451.12890-24-ojeda@kernel.org>
2022-05-07  7:55   ` [PATCH v6 23/23] [RFC] drivers: android: Binder IPC " Kees Cook
2022-05-07  8:13     ` Greg Kroah-Hartman
2022-05-09 17:52       ` Todd Kjos
2022-05-07  8:06 ` [PATCH v6 00/23] Rust support Kees Cook
2022-05-08 18:06   ` Matthew Wilcox
2022-05-09  9:39   ` Wei Liu
     [not found] ` <20220507052451.12890-19-ojeda@kernel.org>
2022-05-07  8:15   ` [PATCH v6 18/23] docs: add Rust documentation Kees Cook
2022-05-07  8:45     ` Miguel Ojeda
2022-05-09  4:02   ` Akira Yokosawa [this message]
2022-05-09 10:41     ` Miguel Ojeda
2022-05-09 14:56       ` Akira Yokosawa
2022-05-09 22:37         ` Jonathan Corbet
2022-05-10 11:57           ` Miguel Ojeda
2022-05-09 22:32   ` Jonathan Corbet
2022-05-10  3:14     ` Gaelan Steele
2022-05-10  5:53       ` Josh Triplett
2022-05-11 13:49     ` Miguel Ojeda
     [not found] ` <20220507052451.12890-8-ojeda@kernel.org>
2022-05-07  9:23   ` [PATCH v6 07/23] rust: import upstream `alloc` crate Kees Cook
2022-05-07  9:33     ` Miguel Ojeda
2022-05-07 17:06       ` Kees Cook
2022-05-07 17:30   ` Linus Torvalds
2022-05-07 19:34     ` Miguel Ojeda
2022-05-07  9:29 ` [PATCH v6 00/23] Rust support David Gow
2022-05-07 15:03   ` Miguel Ojeda
2022-05-10  4:44     ` David Gow
2022-05-10 11:36       ` Miguel Ojeda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7e9c2e77-8b70-6e15-3f3d-905ab42b0fcd@gmail.com \
    --to=akiyks@gmail.com \
    --cc=alex.gaynor@gmail.com \
    --cc=ark.email@gmail.com \
    --cc=bobo1239@web.de \
    --cc=bobwxc@email.cn \
    --cc=corbet@lwn.net \
    --cc=dxu@dxuuu.xyz \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=jarkko@kernel.org \
    --cc=jtitor@2k36.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=me@jvmerkle.de \
    --cc=me@kloenk.de \
    --cc=michal.lkml@markovi.net \
    --cc=mpe@ellerman.id.au \
    --cc=ndesaulniers@google.com \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=thesven73@gmail.com \
    --cc=torvalds@linux-foundation.org \
    --cc=wedsonaf@google.com \
    --cc=wei.liu@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).