From: Oliver <oohall@gmail.com>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: linux-mips@linux-mips.org, linux-sh@vger.kernel.org,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Linus Walleij <linus.walleij@linaro.org>,
Will Deacon <will.deacon@arm.com>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
"James E.J. Bottomley" <jejb@parisc-linux.org>,
Christoph Hellwig <hch@infradead.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Matt Turner <mattst88@gmail.com>,
Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>,
uclinux-h8-devel@lists.sourceforge.jp,
Vladimir Murzin <vladimir.murzin@arm.com>,
Marc Zyngier <marc.zyngier@arm.com>,
adi-buildroot-devel@lists.sourceforge.net,
Nicholas Piggin <npiggin@gmail.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Thomas Gleixner <tglx@linutronix.de>,
Richard Henderson <rth@twiddle.net>,
linux-cris-kernel@axis.com, Greg Kroah-Hartman <gregkh@linuxfou>
Subject: Re: [PATCH] Extract initrd free logic from arch-specific code.
Date: Thu, 29 Mar 2018 09:37:52 +1100 [thread overview]
Message-ID: <CAOSf1CG8gQjoL5rDMRMcZp=D8jBEQ9JBSG68=CiXnitC+4Kjvg@mail.gmail.com> (raw)
In-Reply-To: <20180328221401.GA14084@n2100.armlinux.org.uk>
On Thu, Mar 29, 2018 at 9:14 AM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
>>
>>
>> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
>> > On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
>> >> On 03/28/2018 10:26 AM, Shea Levy wrote:
>> >>> Now only those architectures that have custom initrd free requirements
>> >>> need to define free_initrd_mem.
>> >> ...
>> >>> --- a/arch/arc/mm/init.c
>> >>> +++ b/arch/arc/mm/init.c
>> >>> @@ -229,10 +229,3 @@ void __ref free_initmem(void)
>> >>> {
>> >>> free_initmem_default(-1);
>> >>> }
>> >>> -
>> >>> -#ifdef CONFIG_BLK_DEV_INITRD
>> >>> -void __init free_initrd_mem(unsigned long start, unsigned long end)
>> >>> -{
>> >>> - free_reserved_area((void *)start, (void *)end, -1, "initrd");
>> >>> -}
>> >>> -#endif
>> >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> >>> index 3f972e83909b..19d1c5594e2d 100644
>> >>> --- a/arch/arm/Kconfig
>> >>> +++ b/arch/arm/Kconfig
>> >>> @@ -47,6 +47,7 @@ config ARM
>> >>> select HARDIRQS_SW_RESEND
>> >>> select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
>> >>> select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
>> >>> + select HAVE_ARCH_FREE_INITRD_MEM
>> >>> select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
>> >>> select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
>> >>> select HAVE_ARCH_MMAP_RND_BITS if MMU
>> >>
>> >> Isn't this why weak symbols were invented?
>> >
>> > Weak symbols means that we end up with both the weakly-referenced code
>> > and the arch code in the kernel image. That's fine if the weak code
>> > is small.
>>
>> The kernel's been able to build with link time garbage collection since 2016:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b67067f1176d
>>
>> Wouldn't that remove the unused one?
>
> Probably, if anyone bothered to use that, which they don't.
>
> LD_DEAD_CODE_DATA_ELIMINATION is a symbol without a prompt, and from
> what I can see, nothing selects it. Therefore, the symbol is always
> disabled, and so the feature never gets used in mainline kernels.
>
> Brings up the obvious question - why is it there if it's completely
> unused? (Maybe to cause confusion, and allowing a justification
> for __weak ?)
IIRC Nick had some patches to do the arch enablement for powerpc, but
I'm not sure what happened to them though. I suspect it just fell down
Nick's ever growing TODO list.
next prev parent reply other threads:[~2018-03-28 22:37 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180325221853.10839-1-shea@shealevy.com>
2018-03-28 15:26 ` [PATCH] Extract initrd free logic from arch-specific code Shea Levy
2018-03-28 15:58 ` Rob Landley
2018-03-28 16:04 ` Shea Levy
2018-03-28 16:48 ` Russell King - ARM Linux
2018-03-28 19:04 ` Rob Landley
2018-03-28 22:14 ` Russell King - ARM Linux
2018-03-28 22:37 ` Oliver [this message]
2018-03-29 0:23 ` Nicholas Piggin
2018-03-29 15:27 ` Russell King - ARM Linux
2018-03-29 15:43 ` Geert Uytterhoeven
2018-03-29 15:58 ` Russell King - ARM Linux
2018-03-29 16:53 ` Marc Zyngier
2018-03-29 17:32 ` Russell King - ARM Linux
2018-03-29 17:53 ` Marc Zyngier
2018-03-29 17:43 ` Rob Landley
2018-03-29 16:39 ` Rob Landley
2018-03-29 17:31 ` Russell King - ARM Linux
2018-03-28 16:55 ` Kees Cook
2018-03-29 1:12 ` Wei Yang
2018-03-30 1:43 ` kbuild test robot
2018-03-30 3:16 ` kbuild test robot
2018-03-30 11:15 ` Ingo Molnar
2018-04-01 15:05 ` Shea Levy
2018-04-02 5:59 ` Ingo Molnar
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='CAOSf1CG8gQjoL5rDMRMcZp=D8jBEQ9JBSG68=CiXnitC+4Kjvg@mail.gmail.com' \
--to=oohall@gmail.com \
--cc=Eugeniy.Paltsev@synopsys.com \
--cc=adi-buildroot-devel@lists.sourceforge.net \
--cc=benh@kernel.crashing.org \
--cc=catalin.marinas@arm.com \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfou \
--cc=hch@infradead.org \
--cc=jejb@parisc-linux.org \
--cc=linus.walleij@linaro.org \
--cc=linux-cris-kernel@axis.com \
--cc=linux-mips@linux-mips.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=marc.zyngier@arm.com \
--cc=mattst88@gmail.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=paulus@samba.org \
--cc=rth@twiddle.net \
--cc=tglx@linutronix.de \
--cc=uclinux-h8-devel@lists.sourceforge.jp \
--cc=viro@zeniv.linux.org.uk \
--cc=vladimir.murzin@arm.com \
--cc=will.deacon@arm.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).