Messages in this thread | | | Subject | Re: [PATCH] RISC-V: Make CONFIG_RELOCATABLE user selectable | From | Alexandre ghiti <> | Date | Wed, 27 Oct 2021 07:07:44 +0200 |
| |
Hi Palmer,
On 10/26/21 11:28 PM, Palmer Dabbelt wrote: > From: Palmer Dabbelt <palmerdabbelt@google.com> > > This should really be up to the user, as it trades off portability for > performance. > > Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com> > --- > arch/riscv/Kconfig | 24 ++++++++++++------------ > 1 file changed, 12 insertions(+), 12 deletions(-) > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > index 5dea03549493..f8a36034d54b 100644 > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -212,18 +212,6 @@ config PGTABLE_LEVELS > config LOCKDEP_SUPPORT > def_bool y > > -config RELOCATABLE > - bool > - depends on MMU && 64BIT && !XIP_KERNEL > - help > - This builds a kernel as a Position Independent Executable (PIE), > - which retains all relocation metadata required to relocate the > - kernel binary at runtime to a different virtual address than the > - address it was linked at. > - Since RISCV uses the RELA relocation format, this requires a > - relocation pass at runtime even if the kernel is loaded at the > - same address it was linked at. > - > source "arch/riscv/Kconfig.socs" > source "arch/riscv/Kconfig.erratas" > > @@ -433,6 +421,18 @@ config CRASH_DUMP > > For more details see Documentation/admin-guide/kdump/kdump.rst > > +config RELOCATABLE > + bool "Build a relocatable kernel" > + depends on MMU && 64BIT && !XIP_KERNEL > + help > + This builds a kernel as a Position Independent Executable (PIE), > + which retains all relocation metadata required to relocate the > + kernel binary at runtime to a different virtual address than the > + address it was linked at. > + Since RISCV uses the RELA relocation format, this requires a > + relocation pass at runtime even if the kernel is loaded at the > + same address it was linked at. > + > endmenu > > menu "Boot options"
Agreed, you can add:
Reviewed-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
Thanks for the patch,
Alex
| |