From: Thomas Gleixner <tglx@linutronix.de>
To: "Thomas Weißschuh" <thomas.weissschuh@linutronix.de>,
"Guo Ren" <guoren@kernel.org>,
"Heiko Carstens" <hca@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
"Christian Borntraeger" <borntraeger@linux.ibm.com>,
"Sven Schnelle" <svens@linux.ibm.com>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Will Deacon" <will@kernel.org>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Russell King" <linux@armlinux.org.uk>,
"Huacai Chen" <chenhuacai@kernel.org>,
"WANG Xuerui" <kernel@xen0n.name>,
"Theodore Ts'o" <tytso@mit.edu>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
"Andy Lutomirski" <luto@kernel.org>,
"Peter Zijlstra" <peterz@infradead.org>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
"Michael Ellerman" <mpe@ellerman.id.au>,
"Nicholas Piggin" <npiggin@gmail.com>,
"Christophe Leroy" <christophe.leroy@csgroup.eu>,
"Naveen N Rao" <naveen@kernel.org>,
"Madhavan Srinivasan" <maddy@linux.ibm.com>,
"Vincenzo Frascino" <vincenzo.frascino@arm.com>
Cc: "Christophe Leroy" <christophe.leroy@csgroup.eu>,
linux-csky@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-s390@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-riscv@lists.infradead.org, loongarch@lists.linux.dev,
linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
"Thomas Weißschuh" <thomas.weissschuh@linutronix.de>,
"Nam Cao" <namcao@linutronix.de>
Subject: Re: [PATCH 00/28] vdso: Preparations for generic data storage
Date: Wed, 30 Oct 2024 12:39:45 +0100 [thread overview]
Message-ID: <871pzxzuny.ffs@tglx> (raw)
In-Reply-To: <20241010-vdso-generic-base-v1-0-b64f0842d512@linutronix.de>
Folks!
On Thu, Oct 10 2024 at 09:01, Thomas Weißschuh wrote:
> Historically each architecture defined their own datapage to store the
> VDSO data. This stands in contrast to the generic nature of the VDSO
> code itself.
> We plan to introduce a generic framework for the management of the VDSO
> data storage that can be used by all architectures and which works
> together with the existing generic VDSO code.
>
> Before that is possible align the different architectures by
> standardizing on the existing generic infrastructure and moving things
> out of the VDSO data page which does not belong there.
>
> Patches 1- 2: csky
> Patch 3: s390
> Patches 4- 5: arm64
> Patch 6: riscv
> Patch 7: arm
> Patch 8: LoongArch
> Patch 9: MIPS
> Patches 10-20: x86
> Patches 21-27: powerpc
> Patch 28: Renamings to avoid a name clash with the new code.
As this has been sitting for two weeks now without major comments, I'm
planning to merge that through the tip tree tomorrow.
Thanks,
tglx
next prev parent reply other threads:[~2024-10-30 11:52 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-10 7:01 [PATCH 00/28] vdso: Preparations for generic data storage Thomas Weißschuh
2024-10-10 7:01 ` [PATCH 01/28] csky/vdso: Remove gettimeofday() and friends from VDSO Thomas Weißschuh
2024-10-10 7:01 ` [PATCH 02/28] csky/vdso: Remove arch_vma_name() Thomas Weißschuh
2024-10-10 7:01 ` [PATCH 03/28] s390/vdso: Drop LBASE_VDSO Thomas Weißschuh
2024-10-10 7:54 ` Heiko Carstens
2024-10-10 7:01 ` [PATCH 04/28] arm64: vdso: " Thomas Weißschuh
2024-10-28 18:01 ` Will Deacon
2024-10-10 7:01 ` [PATCH 05/28] arm64: vdso: Use only one single vvar mapping Thomas Weißschuh
2024-10-28 18:39 ` Will Deacon
2024-10-10 7:01 ` [PATCH 06/28] riscv: " Thomas Weißschuh
2024-10-10 7:01 ` [PATCH 07/28] arm: vdso: Remove assembly for datapage access Thomas Weißschuh
2024-10-10 7:01 ` [PATCH 08/28] LoongArch: vDSO: Use vdso/datapage.h to access vDSO data Thomas Weißschuh
2024-10-10 7:01 ` [PATCH 09/28] MIPS: vdso: Avoid name conflict around "vdso_data" Thomas Weißschuh
2024-10-10 7:01 ` [PATCH 10/28] x86/mm/mmap: Remove arch_vma_name() Thomas Weißschuh
2024-10-10 7:01 ` [PATCH 11/28] x86: vdso: Use __arch_get_vdso_data() to access vdso data Thomas Weißschuh
2024-10-10 7:01 ` [PATCH 12/28] x86: vdso: Place vdso_data at beginning of vvar page Thomas Weißschuh
2024-10-10 7:01 ` [PATCH 13/28] x86: vdso: Access rng data from kernel without vvar Thomas Weißschuh
2024-10-10 7:01 ` [PATCH 14/28] x86: vdso: Allocate vvar page from C code Thomas Weißschuh
2024-10-10 7:01 ` [PATCH 15/28] x86: vdso: Access timens vdso data without vvar.h Thomas Weißschuh
2024-10-10 7:01 ` [PATCH 16/28] x86: vdso: Access rng " Thomas Weißschuh
2024-10-10 7:01 ` [PATCH 17/28] x86: vdso: Move the rng offset to vsyscall.h Thomas Weißschuh
2024-10-10 7:01 ` [PATCH 18/28] x86: vdso: Access vdso data without vvar.h Thomas Weißschuh
2024-10-10 7:01 ` [PATCH 19/28] x86: vdso: Delete vvar.h Thomas Weißschuh
2024-10-10 7:01 ` [PATCH 20/28] x86: vdso: Split virtual clock pages into dedicated mapping Thomas Weißschuh
2024-10-10 7:01 ` [PATCH 21/28] powerpc: vdso: Remove offset comment from 32bit vdso_arch_data Thomas Weißschuh
2024-10-10 7:01 ` [PATCH 22/28] powerpc: procfs: Propagate error of remap_pfn_range() Thomas Weißschuh
2024-10-10 7:01 ` [PATCH 23/28] powerpc/pseries/lparcfg: Fix printing of system_active_processors Thomas Weißschuh
2024-10-10 7:01 ` [PATCH 24/28] powerpc/pseries/lparcfg: Use num_possible_cpus() for potential processors Thomas Weißschuh
2024-10-10 7:01 ` [PATCH 25/28] powerpc: Add kconfig option for the systemcfg page Thomas Weißschuh
2024-10-10 7:01 ` [PATCH 26/28] powerpc: Split systemcfg data out of vdso data page Thomas Weißschuh
2024-10-10 7:01 ` [PATCH 27/28] powerpc: Split systemcfg struct definitions out from vdso Thomas Weißschuh
2024-10-10 7:01 ` [PATCH 28/28] vdso: Rename struct arch_vdso_data to arch_vdso_time_data Thomas Weißschuh
2024-10-10 7:55 ` Heiko Carstens
2024-10-30 11:39 ` Thomas Gleixner [this message]
2024-11-05 14:04 ` [PATCH 00/28] vdso: Preparations for generic data storage Christophe Leroy
2024-11-06 7:06 ` Michael Ellerman
2024-12-11 22:33 ` patchwork-bot+linux-riscv
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=871pzxzuny.ffs@tglx \
--to=tglx@linutronix.de \
--cc=Jason@zx2c4.com \
--cc=agordeev@linux.ibm.com \
--cc=aou@eecs.berkeley.edu \
--cc=borntraeger@linux.ibm.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=dave.hansen@linux.intel.com \
--cc=gor@linux.ibm.com \
--cc=guoren@kernel.org \
--cc=hca@linux.ibm.com \
--cc=hpa@zytor.com \
--cc=kernel@xen0n.name \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=loongarch@lists.linux.dev \
--cc=luto@kernel.org \
--cc=maddy@linux.ibm.com \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=namcao@linutronix.de \
--cc=naveen@kernel.org \
--cc=npiggin@gmail.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=peterz@infradead.org \
--cc=svens@linux.ibm.com \
--cc=thomas.weissschuh@linutronix.de \
--cc=tsbogend@alpha.franken.de \
--cc=tytso@mit.edu \
--cc=vincenzo.frascino@arm.com \
--cc=will@kernel.org \
--cc=x86@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).