From: Bernd Schmidt <bernds_cb1@t-online.de>
To: Paul Mundt <lethal@linux-sh.org>,
David McCullough <David_Mccullough@securecomputing.com>,
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 14:04:26 +0200 [thread overview]
Message-ID: <46F261CA.50201@t-online.de> (raw)
In-Reply-To: <20070920031807.GA31263@linux-sh.org>
Paul Mundt wrote:
> I find it a bit disconcerting that blackfin already depends on this
> in-tree without there being any earlier discussion on making these
> changes.
Parts of the initial submission were picked up (the include/asm
directory), other's weren't. Little we can do about that.
>>>> */
>>>> 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.
What is flat_set_persistent other than a stub to validate the relval?
I'm not at all sure what you're proposing or how it would be different.
> load_flat_file() is ugly enough without dumping more architecture
> callback abuses in it.
The other maintainers who have spoken up didn't seem to think this was
ugly, or an abuse. I'm surprised to hear language like that when
discussing a patch that adds an if statement, a local variable and one
parameter in a function call.
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
next prev parent reply other threads:[~2007-09-20 12:05 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
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 [this message]
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=46F261CA.50201@t-online.de \
--to=bernds_cb1@t-online.de \
--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=lethal@linux-sh.org \
--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 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.