From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: Rob Landley <rob@landley.net>
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,
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@linuxfoundation.org>,
linux-kernel@vger.kerne
Subject: Re: [PATCH] Extract initrd free logic from arch-specific code.
Date: Wed, 28 Mar 2018 23:14:01 +0100 [thread overview]
Message-ID: <20180328221401.GA14084@n2100.armlinux.org.uk> (raw)
In-Reply-To: <de092e7f-0bc9-bb06-9798-12784930a6bd@landley.net>
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 ?)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
next prev parent reply other threads:[~2018-03-28 22:14 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 [this message]
2018-03-28 22:37 ` Oliver
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=20180328221401.GA14084@n2100.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--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@linuxfoundation.org \
--cc=hch@infradead.org \
--cc=jejb@parisc-linux.org \
--cc=linus.walleij@linaro.org \
--cc=linux-cris-kernel@axis.com \
--cc=linux-kernel@vger.kerne \
--cc=linux-mips@linux-mips.org \
--cc=linux-sh@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=mattst88@gmail.com \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
--cc=rob@landley.net \
--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).