Re: [PATCH v2] Documentation/page_tables: Add info about MMU/TLB and Page Faults

["Fabio M. De Francesco" <fmdefrancesco@gmail.com>]

On martedì 15 agosto 2023 10:51:24 CEST Linus Walleij wrote:
> Hi Fabio,
> 
> overall this v2 looks good!

Hi Linus,

Thanks for your review. I appreciated it.

I'm counting at least ten mistakes. Well my poor English should still improve 
in order to work on documentation.

I agree with you on all changes you are proposing, so I won't agree line by 
line. Instead I'll send a v3 and forward your tag. 

I have only a doubt and a questions. 
I'll jump directly to the relevant parts.

> 
> The below are my grammar and spelling nitpicks.
>
> [snip] 
> 
> > +If the above-mentioned conditions happen in user-space, the kernel sends 
a
> > +`Segmentation Fault` (SIGSEGV) signal to the current thread. That signal
> > usually +causes the termination of the thread and of the process it 
belongs
> > to. +
> > +Instead, there are also common and expected other causes of page faults.
> > These
> The word you are looking for is "Additionally" right?
> 
> "Additionally, there are..."

I was only able to use "Instead" to express that, contrary to the former 
conditions that is unexpected and uncommon, there are other expected and 
common causes of page faults. I thought that "Instead" stresses that the 
latter causes carry with them opposite and wanted consequences.

I think of "additionally" as a means to introduce less important and less 
frequently occurring conditions.

Nevertheless, I'll change it to "Additionally" as you are asking for.

Everything that follows from here onward should surely be changed as you are 
suggesting.  

[snip]

> > +Swapping can't work for memory mapped by kernel logical addresses. These
> > are a
> "kernel logical addresses" -> "kernel-internal logical addresses"

My only question is about why you prefer "kernel-internal" to a straight 
"kernel". Can you please say more about this?

[snip]
 
> With
> or without the above suggestions:

I'll do the v3 _with_ the above suggestions.

> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> 
> Yours,
> Linus Walleij

Again thanks,

Fabio