[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 6 May 2019 16:50:59 -0300
From: Mauro Carvalho Chehab <mchehab+samsung@...nel.org>
To: Linux Doc Mailing List <linux-doc@...r.kernel.org>
Cc: Peter Zijlstra <peterz@...radead.org>, Borislav Petkov <bp@...en8.de>,
Jonathan Corbet <corbet@....net>, Mike Snitzer <snitzer@...hat.com>, Mauro
Carvalho Chehab <mchehab@...radead.org>, linux-kernel@...r.kernel.org,
Johannes Berg <johannes@...solutions.net>, Kurt Schwemmer
<kurt.schwemmer@...rosemi.com>, Logan Gunthorpe <logang@...tatee.com>,
Bjorn Helgaas <bhelgaas@...gle.com>, Alasdair Kergon <agk@...hat.com>,
dm-devel@...hat.com, Kishon Vijay Abraham I <kishon@...com>, Rob Herring
<robh+dt@...nel.org>, Mark Rutland <mark.rutland@....com>, Bartlomiej
Zolnierkiewicz <b.zolnierkie@...sung.com>, David Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel@...ll.ch>, Maarten Lankhorst
<maarten.lankhorst@...ux.intel.com>, Maxime Ripard
<maxime.ripard@...tlin.com>, Sean Paul <sean@...rly.run>, Ning Sun
<ning.sun@...el.com>, Ingo Molnar <mingo@...hat.com>, Will Deacon
<will.deacon@....com>, Alan Stern <stern@...land.harvard.edu>, Andrea Parri
<andrea.parri@...rulasolutions.com>, Boqun Feng <boqun.feng@...il.com>,
Nicholas Piggin <npiggin@...il.com>, David Howells <dhowells@...hat.com>,
Jade Alglave <j.alglave@....ac.uk>, Luc Maranget <luc.maranget@...ia.fr>,
"Paul E. McKenney" <paulmck@...ux.ibm.com>, Akira Yokosawa
<akiyks@...il.com>, Daniel Lustig <dlustig@...dia.com>, "David S. Miller"
<davem@...emloft.net>, Andreas Färber <afaerber@...e.de>,
Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>, Cornelia Huck
<cohuck@...hat.com>, Farhan Ali <alifm@...ux.ibm.com>, Eric Farman
<farman@...ux.ibm.com>, Halil Pasic <pasic@...ux.ibm.com>, Martin
Schwidefsky <schwidefsky@...ibm.com>, Heiko Carstens
<heiko.carstens@...ibm.com>, Harry Wei <harryxiyou@...il.com>, Alex Shi
<alex.shi@...ux.alibaba.com>, Jerry Hoemann <jerry.hoemann@....com>, Wim
Van Sebroeck <wim@...ux-watchdog.org>, Guenter Roeck <linux@...ck-us.net>,
Thomas Gleixner <tglx@...utronix.de>, "H. Peter Anvin" <hpa@...or.com>,
x86@...nel.org, Russell King <linux@...linux.org.uk>, Tony Luck
<tony.luck@...el.com>, Fenghua Yu <fenghua.yu@...el.com>, "James E.J.
Bottomley" <James.Bottomley@...senPartnership.com>, Helge Deller
<deller@....de>, Yoshinori Sato <ysato@...rs.sourceforge.jp>, Rich Felker
<dalias@...c.org>, Guan Xuetao <gxt@....edu.cn>, Jens Axboe
<axboe@...nel.dk>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "Rafael
J. Wysocki" <rafael@...nel.org>, Arnd Bergmann <arnd@...db.de>, Matt
Mackall <mpm@...enic.com>, Herbert Xu <herbert@...dor.apana.org.au>, Corey
Minyard <minyard@....org>, Sumit Semwal <sumit.semwal@...aro.org>, Linus
Walleij <linus.walleij@...aro.org>, Bartosz Golaszewski
<bgolaszewski@...libre.com>, Darren Hart <dvhart@...radead.org>, Andy
Shevchenko <andy@...radead.org>, Stuart Hayes <stuart.w.hayes@...il.com>,
Jaroslav Kysela <perex@...ex.cz>, Alex Williamson
<alex.williamson@...hat.com>, Kirti Wankhede <kwankhede@...dia.com>,
Christoph Hellwig <hch@....de>, Marek Szyprowski
<m.szyprowski@...sung.com>, Robin Murphy <robin.murphy@....com>, Steffen
Klassert <steffen.klassert@...unet.com>, Kees Cook <keescook@...omium.org>,
Emese Revfy <re.emese@...il.com>, James Morris <jmorris@...ei.org>, "Serge
E. Hallyn" <serge@...lyn.com>, linux-wireless@...r.kernel.org,
linux-pci@...r.kernel.org, devicetree@...r.kernel.org,
dri-devel@...ts.freedesktop.org, linux-fbdev@...r.kernel.org,
tboot-devel@...ts.sourceforge.net, linux-arch@...r.kernel.org,
netdev@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-s390@...r.kernel.org, kvm@...r.kernel.org,
linux-watchdog@...r.kernel.org, linux-ia64@...r.kernel.org,
linux-parisc@...r.kernel.org, linux-sh@...r.kernel.org,
sparclinux@...r.kernel.org, linux-block@...r.kernel.org,
linux-crypto@...r.kernel.org, openipmi-developer@...ts.sourceforge.net,
linaro-mm-sig@...ts.linaro.org, linux-gpio@...r.kernel.org,
platform-driver-x86@...r.kernel.org, iommu@...ts.linux-foundation.org,
linux-mm@...ck.org, kernel-hardening@...ts.openwall.com,
linux-security-module@...r.kernel.org, Changbin Du <changbin.du@...il.com>
Subject: Re: [PATCH v2 56/79] docs: Documentation/*.txt: rename all ReST
files to *.rst
Em Wed, 24 Apr 2019 08:52:09 +0200
Peter Zijlstra <peterz@...radead.org> escreveu:
> On Tue, Apr 23, 2019 at 11:38:16PM +0200, Borislav Petkov wrote:
> > If that is all the changes it would need, then I guess that's ok. Btw,
> > those rst-conversion patches don't really show what got changed. Dunno
> > if git can even show that properly. I diffed the two files by hand to
> > see what got changed, see end of mail.
>
> That is not a happy diff; that table has gotten waay worse to read due
> to all that extra table crap.
Not that I'm proposing such change, but, as a reference, I just discovered
today that there's a way to make it even lighter than it is while still
showing it as a table:
================= ======== == ================ ===== == ===========================================================
Start addr Offset End addr Size VM area description
----------------- ----------- ---------------- -------- -----------------------------------------------------------
0000000000000000 0 00007fffffffffff 128 TB user-space virtual memory, different per mm
0000800000000000 +128 TB ffff7fffffffffff ~16M TB ... huge, almost 64 bits wide hole of non-canonical
virtual memory addresses up to the -128 TB
starting offset of kernel mappings.
----------------- -------- -- ---------------- ----- -- -----------------------------------------------------------
- Kernel-space virtual memory, shared between all processes:
----------------- ----------- ---------------- -------- -----------------------------------------------------------
ffff800000000000 -128 TB ffff87ffffffffff 8 TB ... guard hole, also reserved for hypervisor
ffff880000000000 -120 TB ffff887fffffffff 0.5 TB LDT remap for PTI
ffff888000000000 -119.5 TB ffffc87fffffffff 64 TB direct mapping of all physical memory (page_offset_base)
ffffc88000000000 -55.5 TB ffffc8ffffffffff 0.5 TB ... unused hole
ffffc90000000000 -55 TB ffffe8ffffffffff 32 TB vmalloc/ioremap space (vmalloc_base)
ffffe90000000000 -23 TB ffffe9ffffffffff 1 TB ... unused hole
ffffea0000000000 -22 TB ffffeaffffffffff 1 TB virtual memory map (vmemmap_base)
ffffeb0000000000 -21 TB ffffebffffffffff 1 TB ... unused hole
ffffec0000000000 -20 TB fffffbffffffffff 16 TB KASAN shadow memory
----------------- -------- -- ---------------- ----- -- -----------------------------------------------------------
- Identical layout to the 56-bit one from here on:
----------------- ----------- ---------------- -------- -----------------------------------------------------------
fffffc0000000000 -4 TB fffffdffffffffff 2 TB ... unused hole
vaddr_end for KASLR
fffffe0000000000 -2 TB fffffe7fffffffff 0.5 TB cpu_entry_area mapping
fffffe8000000000 -1.5 TB fffffeffffffffff 0.5 TB ... unused hole
ffffff0000000000 -1 TB ffffff7fffffffff 0.5 TB %esp fixup stacks
ffffff8000000000 -512 GB ffffffeeffffffff 444 GB ... unused hole
ffffffef00000000 -68 GB fffffffeffffffff 64 GB EFI region mapping space
ffffffff00000000 -4 GB ffffffff7fffffff 2 GB ... unused hole
ffffffff80000000 -2 GB ffffffff9fffffff 512 MB kernel text mapping, mapped to physical address 0
ffffffff80000000 -2048 MB
ffffffffa0000000 -1536 MB fffffffffeffffff 1520 MB module mapping space
ffffffffff000000 -16 MB
FIXADDR_START ~-11 MB ffffffffff5fffff ~0.5 MB kernel-internal fixmap range, variable size and offset
ffffffffff600000 -10 MB ffffffffff600fff 4 kB legacy vsyscall ABI
ffffffffffe00000 -2 MB ffffffffffffffff 2 MB ... unused hole
================= ======== == ================ ===== == ===========================================================
If one wants the table headers as such, an extra line is required:
================= ======== == ================ ===== == ===========================================================
Start addr Offset End addr Size VM area description
----------------- ----------- ---------------- -------- -----------------------------------------------------------
================= ======== == ================ ===== == ===========================================================
<snip/>
================= ======== == ================ ===== == ===========================================================
The output using this approach and a markup to use mono-spaced cells
e. g. either using ..raw or using .. cssclass as commented before in
this thread is at:
https://www.infradead.org/~mchehab/rst_conversion/x86/x86_64/mm_alternative.html
Just converted the first table, keeping the other as a literal block.
Thanks,
Mauro
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
