From: Paul Mundt <lethal@linux-sh.org>
To: David McCullough <David_Mccullough@securecomputing.com>
Cc: Robin Getz <rgetz@blackfin.uclinux.org>,
uclinux-dist-devel@blackfin.uclinux.org, bryan.wu@analog.com,
Bernd Schmidt <bernd.schmidt@analog.com>,
Greg Ungerer <gerg@snapgear.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
ysato@users.sourceforge.jp, miles@lsi.nec.co.jp,
linux-m32r@ml.linux-m32r.org
Subject: Re: [PATCH] binfmt_flat: minimum support for theBlackfin relocations
Date: Thu, 20 Sep 2007 12:18:07 +0900 [thread overview]
Message-ID: <20070920031807.GA31263@linux-sh.org> (raw)
In-Reply-To: <20070920015525.GA16615@securecomputing.com>
On Thu, Sep 20, 2007 at 11:55:25AM +1000, David McCullough wrote:
> Jivin Robin Getz lays it down ...
> > On Tue 18 Sep 2007 04:09, Bryan Wu pondered:
> > > This just adds minimum support for the Blackfin relocations,
> > > since we don't have enough space in each reloc. The idea
> > > is to store a value with one relocation so that subsequent ones can
> > > access it.
> >
> > Adding the other appropriate maintainers. for h8, m32r, sh and v850.
>
> Looks fine to me, obviously impacts the existing arches very little.
> Can't see why it shouldn't get included,
>
I find it a bit disconcerting that blackfin already depends on this
in-tree without there being any earlier discussion on making these
changes.
> > > */
> > > if (rev > OLD_FLAT_VERSION) {
> > > + unsigned long persistent = 0;
> > > for (i=0; i < relocs; i++) {
> > > unsigned long addr, relval;
> > >
> > > @@ -749,6 +750,8 @@ static int load_flat_file(struct linux_binprm * bprm,
> > > relocated (of course, the address has to be
> > > relocated first). */
> > > relval = ntohl(reloc[i]);
> > > + if (flat_set_persistent (relval, &persistent))
> > > + continue;
> > > addr = flat_get_relocate_addr(relval);
> > > rp = (unsigned long *) calc_reloc(addr, libinfo, id, 1);
> > > if (rp == (unsigned long *)RELOC_FAILED) {
I don't much care for this API. It's shuffling around a temporary
variable for the architecture code that's set for certain relocations
that are otherwise unhandled.
Since all the architecture is interested in is the relval that has
associated "persistent" data encoded in it, why don't we just have a stub
to give the architecture a chance to validate the relval before the
flat_get_relocate_addr() and move this stuff there instead? ie, blackfin
takes this out-of-line and manages its persistent value there.
> > > @@ -757,7 +760,7 @@ static int load_flat_file(struct linux_binprm * bprm,
> > > }
> > >
> > > /* Get the pointer's value. */
> > > - addr = flat_get_addr_from_rp(rp, relval, flags);
> > > + addr = flat_get_addr_from_rp(rp, relval, flags, &persistent);
There's no reason for this to be a pointer. The current in-tree blackfin
code doesn't change this value, and if you have patches that are doing
that, this is even more reason to bury this kind of silliness in your
architecture code.
load_flat_file() is ugly enough without dumping more architecture
callback abuses in it.
next prev parent reply other threads:[~2007-09-20 3:18 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-18 8:09 [PATCH] binfmt_flat: minimum support for the Blackfin relocations Bryan Wu
2007-09-19 15:52 ` [Uclinux-dist-devel] " Bryan Wu
2007-09-20 1:31 ` [PATCH] binfmt_flat: minimum support for theBlackfin relocations Robin Getz
2007-09-20 1:55 ` David McCullough
2007-09-20 2:46 ` Robin Getz
2007-09-20 3:18 ` Paul Mundt [this message]
2007-09-20 3:42 ` Mike Frysinger
2007-09-20 3:54 ` Paul Mundt
2007-09-20 6:08 ` Robin Getz
2007-09-20 6:34 ` Bryan Wu
2007-09-20 6:41 ` Bryan Wu
2007-09-20 7:35 ` Miles Bader
2007-09-20 12:04 ` Bernd Schmidt
2007-09-20 14:25 ` Paul Mundt
2007-09-20 14:56 ` Bernd Schmidt
2007-09-20 15:03 ` David McCullough
2007-09-21 1:44 ` Robin Getz
2007-09-21 3:32 ` David McCullough
2007-09-28 15:46 ` Bryan Wu
2007-09-20 7:42 ` Hirokazu Takata
2007-09-28 23:08 ` [PATCH] binfmt_flat: minimum support for the Blackfin relocations Andrew Morton
2007-09-28 23:48 ` Bernd Schmidt
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=20070920031807.GA31263@linux-sh.org \
--to=lethal@linux-sh.org \
--cc=David_Mccullough@securecomputing.com \
--cc=akpm@linux-foundation.org \
--cc=bernd.schmidt@analog.com \
--cc=bryan.wu@analog.com \
--cc=gerg@snapgear.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m32r@ml.linux-m32r.org \
--cc=miles@lsi.nec.co.jp \
--cc=rgetz@blackfin.uclinux.org \
--cc=uclinux-dist-devel@blackfin.uclinux.org \
--cc=ysato@users.sourceforge.jp \
/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