Documentation: riscv: tableize memory layout

  The memory layout is written as table but it is inside literal code
block, which renders as preformatted text. Write the layout in reST
grid table instead.

Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
---
 Documentation/riscv/vm-layout.rst | 120 +++++++++++++++---------------
 1 file changed, 58 insertions(+), 62 deletions(-)


base-commit: 0cdb3579f1ee4c1e55acf8dfb0697b660067b1f8
  

On Sun, Nov 06, 2022 at 05:02:40PM +0700, Bagas Sanjaya wrote:
> Documentation: riscv: tableize memory layout

Minor nit about the $subject - but this is the docs, so I guess there's
nowhere better to mention grammar: "tableize" is not a word. I think
what you want here is "tabulate".

> The memory layout is written as table but it is inside literal code
                                 ^ as a table           ^ inside a

Anyway, those are minor nits I saw in passing, one actual comment and a
simple question below.
Thanks,
Conor.

> block, which renders as preformatted text. Write the layout in reST
> grid table instead.
> 
> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
> ---
>  Documentation/riscv/vm-layout.rst | 120 +++++++++++++++---------------
>  1 file changed, 58 insertions(+), 62 deletions(-)
> 
> diff --git a/Documentation/riscv/vm-layout.rst b/Documentation/riscv/vm-layout.rst
> index 5b36e45fef60bd..139320e35de81f 100644
> --- a/Documentation/riscv/vm-layout.rst
> +++ b/Documentation/riscv/vm-layout.rst
> @@ -30,70 +30,66 @@ the RISC-V Linux Kernel resides.
>  RISC-V Linux Kernel SV39
>  ------------------------
>  
> -::
> -
> -  ========================================================================================================================
> -      Start addr    |   Offset   |     End addr     |  Size   | VM area description
> -  ========================================================================================================================
> -                    |            |                  |         |
> -   0000000000000000 |    0       | 0000003fffffffff |  256 GB | user-space virtual memory, different per mm
> -  __________________|____________|__________________|_________|___________________________________________________________
> -                    |            |                  |         |
> -   0000004000000000 | +256    GB | ffffffbfffffffff | ~16M TB | ... huge, almost 64 bits wide hole of non-canonical
> -                    |            |                  |         |     virtual memory addresses up to the -256 GB
> -                    |            |                  |         |     starting offset of kernel mappings.
> -  __________________|____________|__________________|_________|___________________________________________________________
> -                                                              |
> -                                                              | Kernel-space virtual memory, shared between all processes:
> -  ____________________________________________________________|___________________________________________________________
> -                    |            |                  |         |
> -   ffffffc6fee00000 | -228    GB | ffffffc6feffffff |    2 MB | fixmap
> -   ffffffc6ff000000 | -228    GB | ffffffc6ffffffff |   16 MB | PCI io
> -   ffffffc700000000 | -228    GB | ffffffc7ffffffff |    4 GB | vmemmap
> -   ffffffc800000000 | -224    GB | ffffffd7ffffffff |   64 GB | vmalloc/ioremap space
> -   ffffffd800000000 | -160    GB | fffffff6ffffffff |  124 GB | direct mapping of all physical memory
> -   fffffff700000000 |  -36    GB | fffffffeffffffff |   32 GB | kasan
> -  __________________|____________|__________________|_________|____________________________________________________________
> -                                                              |
> -                                                              |
> -  ____________________________________________________________|____________________________________________________________
> -                    |            |                  |         |
> -   ffffffff00000000 |   -4    GB | ffffffff7fffffff |    2 GB | modules, BPF
> -   ffffffff80000000 |   -2    GB | ffffffffffffffff |    2 GB | kernel
> -  __________________|____________|__________________|_________|____________________________________________________________
> +   +------------------+---------+------------------+---------+----------------------------------------------------------+
> +   |    Start addr    | Offset  |     End addr     |  Size   | VM area description                                      |
> +   +==================+=========+==================+=========+==========================================================+
> +   | 0000000000000000 |    0    | 0000003fffffffff | 256 GB  | user-space virtual memory, different per mm              |
> +   +------------------+---------+------------------+---------+----------------------------------------------------------+
> +   | 0000004000000000 | +256 GB | ffffffbfffffffff | ~16M TB | ... huge, almost 64 bits wide hole of non-canonical      |
> +   |                  |         |                  |         | virtual memory addresses up to the -256 GB               |
> +   |                  |         |                  |         | starting offset of kernel mappings.                      |
> +   +------------------+---------+------------------+---------+----------------------------------------------------------+
> +   |                             Kernel-space virtual memory, shared between all processes:                             |
> +   +------------------+---------+------------------+---------+----------------------------------------------------------+
> +   | ffffffc6fee00000 | -228 GB | ffffffc6feffffff | 2 MB    | fixmap                                                   |
> +   +------------------+---------+------------------+---------+----------------------------------------------------------+
> +   | ffffffc6ff000000 | -228 GB | ffffffc6ffffffff | 16 MB   | PCI io                                                   |
> +   +------------------+---------+------------------+---------+----------------------------------------------------------+
                                                        ^
Will these numbers remain right-aligned in the formatted doc? They were
aligned before in the text form & no longer appear to be.

> +   | ffffffc700000000 | -228 GB | ffffffc7ffffffff | 4 GB    | vmemmap                                                  |
> +   +------------------+---------+------------------+---------+----------------------------------------------------------+
> +   | ffffffc800000000 | -224 GB | ffffffd7ffffffff | 64 GB   | vmalloc/ioremap space                                    |
> +   +------------------+---------+------------------+---------+----------------------------------------------------------+
> +   | ffffffd800000000 | -160 GB | fffffff6ffffffff | 124 GB  | direct mapping of all physical memory                    |
> +   +------------------+---------+------------------+---------+----------------------------------------------------------+
> +   | fffffff700000000 | -36 GB  | fffffffeffffffff | 32 GB   | kasan                                                    |
> +   +------------------+---------+------------------+---------+----------------------------------------------------------+
> +   |                                  Identical layout to the 39-bit one from here on:                                  |

This one /is/ sv39. I'd leave this as a blank to match the styling in
the original document.

> +   +------------------+---------+------------------+---------+----------------------------------------------------------+
> +   | ffffffff00000000 | -4 GB   | ffffffff7fffffff | 2 GB    | modules, BPF                                             |
> +   +------------------+---------+------------------+---------+----------------------------------------------------------+
> +   | ffffffff80000000 | -2 GB   | ffffffffffffffff | 2 GB    | kernel                                                   |
> +   +------------------+---------+------------------+---------+----------------------------------------------------------+
>  
>
  

Hi Bagas,

On Sun,  6 Nov 2022 17:02:40 +0700, Bagas Sanjaya wrote:
> The memory layout is written as table but it is inside literal code
> block, which renders as preformatted text. Write the layout in reST
> grid table instead.

What's the purpose of this change?

The tables in html/pdf output after this change are almost unreadable
to my eyes due to the proportional font and random wrapping inside
table columns.

I think in this particular case, "literal block" is the right
choice at least for html output, as can be seen at:

   https://www.kernel.org/doc/html/latest/riscv/vm-layout.html
   https://www.kernel.org/doc/html/next/riscv/vm-layout.html

Yes, these very wide tables need horizontal scrolling in the alabaster
theme (in next), but they look much nicer than your version.

In pdf output, wide literal blocks are force-wrapped and don't look good.
Using some smaller font size for latex might help, but most people don't
care much of pdf outputs anyway, I guess.

        Thanks, Akira
> 
> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
> ---
>  Documentation/riscv/vm-layout.rst | 120 +++++++++++++++---------------
>  1 file changed, 58 insertions(+), 62 deletions(-)
  

On 11/6/22 18:22, Conor Dooley wrote:
>> +   +------------------+---------+------------------+---------+----------------------------------------------------------+
>> +   |    Start addr    | Offset  |     End addr     |  Size   | VM area description                                      |
>> +   +==================+=========+==================+=========+==========================================================+
>> +   | 0000000000000000 |    0    | 0000003fffffffff | 256 GB  | user-space virtual memory, different per mm              |
>> +   +------------------+---------+------------------+---------+----------------------------------------------------------+
>> +   | 0000004000000000 | +256 GB | ffffffbfffffffff | ~16M TB | ... huge, almost 64 bits wide hole of non-canonical      |
>> +   |                  |         |                  |         | virtual memory addresses up to the -256 GB               |
>> +   |                  |         |                  |         | starting offset of kernel mappings.                      |
>> +   +------------------+---------+------------------+---------+----------------------------------------------------------+
>> +   |                             Kernel-space virtual memory, shared between all processes:                             |
>> +   +------------------+---------+------------------+---------+----------------------------------------------------------+
>> +   | ffffffc6fee00000 | -228 GB | ffffffc6feffffff | 2 MB    | fixmap                                                   |
>> +   +------------------+---------+------------------+---------+----------------------------------------------------------+
>> +   | ffffffc6ff000000 | -228 GB | ffffffc6ffffffff | 16 MB   | PCI io                                                   |
>> +   +------------------+---------+------------------+---------+----------------------------------------------------------+
>                                                         ^
> Will these numbers remain right-aligned in the formatted doc? They were
> aligned before in the text form & no longer appear to be.
> 

These numbers also become wrapped in their cells.

However, in order to fix alignment of these, custom CSS is needed, similar
to one in StackOverflow [1].

[1]: https://stackoverflow.com/a/7351383

Thanks.
  

On Mon, Nov 07, 2022 at 09:55:31AM +0700, Bagas Sanjaya wrote:
> On 11/6/22 18:22, Conor Dooley wrote:
> >> +   +------------------+---------+------------------+---------+----------------------------------------------------------+
> >> +   |    Start addr    | Offset  |     End addr     |  Size   | VM area description                                      |
> >> +   +==================+=========+==================+=========+==========================================================+
> >> +   | 0000000000000000 |    0    | 0000003fffffffff | 256 GB  | user-space virtual memory, different per mm              |
> >> +   +------------------+---------+------------------+---------+----------------------------------------------------------+
> >> +   | 0000004000000000 | +256 GB | ffffffbfffffffff | ~16M TB | ... huge, almost 64 bits wide hole of non-canonical      |
> >> +   |                  |         |                  |         | virtual memory addresses up to the -256 GB               |
> >> +   |                  |         |                  |         | starting offset of kernel mappings.                      |
> >> +   +------------------+---------+------------------+---------+----------------------------------------------------------+
> >> +   |                             Kernel-space virtual memory, shared between all processes:                             |
> >> +   +------------------+---------+------------------+---------+----------------------------------------------------------+
> >> +   | ffffffc6fee00000 | -228 GB | ffffffc6feffffff | 2 MB    | fixmap                                                   |
> >> +   +------------------+---------+------------------+---------+----------------------------------------------------------+
> >> +   | ffffffc6ff000000 | -228 GB | ffffffc6ffffffff | 16 MB   | PCI io                                                   |
> >> +   +------------------+---------+------------------+---------+----------------------------------------------------------+
> >                                                         ^
> > Will these numbers remain right-aligned in the formatted doc? They were
> > aligned before in the text form & no longer appear to be.
> > 
> 
> These numbers also become wrapped in their cells.
> 
> However, in order to fix alignment of these, custom CSS is needed, similar
> to one in StackOverflow [1].

Hmm. In that case I'd be inclined to agree with Akira that this should
be left as is.

Thanks,
Conor.