All of lore.kernel.org
 help / color / mirror / Atom feed
From: htejun@gmail.com (Tejun Heo)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: use unified discard definition in linker script
Date: Wed, 07 Oct 2009 19:41:50 +0900	[thread overview]
Message-ID: <4ACC706E.5000002@gmail.com> (raw)
In-Reply-To: <4ACC6D74.7010001@tuffmail.co.uk>

Alan Jenkins wrote:
> I selfishly request an Acked-by for the following. My aim is to submit it as
> part of a larger series ("module: Speed up symbol resolution during module
> loading") which would not go through the ARM tree.
> 
> ------------------------------------------------------------------->
> From 52c4a00b22fecf3ecb352618356bb61f7f4b261b Mon Sep 17 00:00:00 2001
> From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
> Date: Wed, 7 Oct 2009 11:08:34 +0100
> Subject: [PATCH] arm: use unified discard definition in linker script
> 
> Commit 023bf6f "linker script: unify usage of discard definition"
> changed the linker scripts for all architectures except for ARM.
> I can find no discussion about this exception, so here are the changes
> for ARM.
> 
> These changes are exactly parallel to the ia64 case.
> 
> "ia64 is notable because it first throws away some ia64 specific
>  subsections and then include the rest of the sections into the final
>  image, so those sections must be discarded before the inclusion."
> 
> Not boot-tested.  In build testing, the modified linker script generated
> an identical vmlinux file.
> 
> 
> [I would like to be able to rely on this unified discard definition.
>  I want to sort the kernel symbol tables to allow faster symbol
>  resolution during module loading. The simplest way appears to be
>  to generate sorted versions from vmlinux.o, link them in to vmlinux,
>  _and discard the original unsorted tables_.
> 
>  This work is driven by my x86 netbook, but it is implemented at a
>  generic level. It is possible it will benefit some ARM systems also.]
> 
> 
> Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
> CC: Tejun Heo <tj@kernel.org>

Most likely omission by simple mistake.  The change looks fine to me
but I don't have any arm machine to test it.

Acked-by-without-testing: Tejun Heo <tj@kernel.org>

-- 
tejun

WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <htejun@gmail.com>
To: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [PATCH] arm: use unified discard definition in linker script
Date: Wed, 07 Oct 2009 19:41:50 +0900	[thread overview]
Message-ID: <4ACC706E.5000002@gmail.com> (raw)
In-Reply-To: <4ACC6D74.7010001@tuffmail.co.uk>

Alan Jenkins wrote:
> I selfishly request an Acked-by for the following. My aim is to submit it as
> part of a larger series ("module: Speed up symbol resolution during module
> loading") which would not go through the ARM tree.
> 
> ------------------------------------------------------------------->
> From 52c4a00b22fecf3ecb352618356bb61f7f4b261b Mon Sep 17 00:00:00 2001
> From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
> Date: Wed, 7 Oct 2009 11:08:34 +0100
> Subject: [PATCH] arm: use unified discard definition in linker script
> 
> Commit 023bf6f "linker script: unify usage of discard definition"
> changed the linker scripts for all architectures except for ARM.
> I can find no discussion about this exception, so here are the changes
> for ARM.
> 
> These changes are exactly parallel to the ia64 case.
> 
> "ia64 is notable because it first throws away some ia64 specific
>  subsections and then include the rest of the sections into the final
>  image, so those sections must be discarded before the inclusion."
> 
> Not boot-tested.  In build testing, the modified linker script generated
> an identical vmlinux file.
> 
> 
> [I would like to be able to rely on this unified discard definition.
>  I want to sort the kernel symbol tables to allow faster symbol
>  resolution during module loading. The simplest way appears to be
>  to generate sorted versions from vmlinux.o, link them in to vmlinux,
>  _and discard the original unsorted tables_.
> 
>  This work is driven by my x86 netbook, but it is implemented at a
>  generic level. It is possible it will benefit some ARM systems also.]
> 
> 
> Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
> CC: Tejun Heo <tj@kernel.org>

Most likely omission by simple mistake.  The change looks fine to me
but I don't have any arm machine to test it.

Acked-by-without-testing: Tejun Heo <tj@kernel.org>

-- 
tejun

  reply	other threads:[~2009-10-07 10:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-07 10:29 [PATCH] arm: use unified discard definition in linker script Alan Jenkins
2009-10-07 10:29 ` Alan Jenkins
2009-10-07 10:41 ` Tejun Heo [this message]
2009-10-07 10:41   ` Tejun Heo
2009-10-07 11:23 ` Russell King - ARM Linux
2009-10-07 11:23   ` Russell King - ARM Linux
  -- strict thread matches above, loose matches on Subject: below --
2009-10-07 10:08 Alan Jenkins

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=4ACC706E.5000002@gmail.com \
    --to=htejun@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.