From: Andrew Morton <akpm@linux-foundation.org>
To: bryan.wu@analog.com
Cc: bernd.schmidt@analog.com, davidm@snapgear.com, gerg@snapgear.com,
linux-kernel@vger.kernel.org,
uclinux-dist-devel@blackfin.uclinux.org
Subject: Re: [PATCH] binfmt_flat: minimum support for the Blackfin relocations
Date: Fri, 28 Sep 2007 16:08:26 -0700 [thread overview]
Message-ID: <20070928160826.1483b9ba.akpm@linux-foundation.org> (raw)
In-Reply-To: <1190102965.4406.9.camel@roc-desktop>
On Tue, 18 Sep 2007 16:09:25 +0800
Bryan Wu <bryan.wu@analog.com> wrote:
> From: Bernd Schmidt <bernd.schmidt@analog.com>
>
> 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.
>
> Actually, this patch is required for Blackfin. Currently if BINFMT_FLAT
> is enabled, git-tree kernel will fail to compile. Please consider to
> accept it.
>
A few things
> diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
> index 7b0265d..13b58f8 100644
> --- a/fs/binfmt_flat.c
> +++ b/fs/binfmt_flat.c
> @@ -742,6 +742,7 @@ static int load_flat_file(struct linux_binprm * bprm,
> * __start to address 4 so that is okay).
> */
> if (rev > OLD_FLAT_VERSION) {
> + unsigned long persistent = 0;
`persistent' here only has meaning inside the next nesting level, so should
be moved down into that scope for readability reasons.
Also, the initialisation to zero is, afaict, unneeded and wastes
instructions. I suspect that's just there to suppress a gcc warning, which
is better done with uninitialized_var().
> 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;
If this correct? flat_set_persistent() returns zero if it didn't write
anything to `persistent'. It seems strange that in the case where
flat_set_persistent() _does_ write something to `persistent', we just throw
it away by doing `continue'.
Either that, or I've misread the code and you really did mean to put
`persistent' in the outer scope, and its value is supposed to propagate
over into the next iteration of the loop. If so, that's all a bit too
tricky for it to be implemented with zero code comments, dontcha think?
Also, given that you are proposing that flat_set_persistent() becomes part
of the kernel's core<->arch interface (for all architectures which want to
implement binfmt_flat()), it is no longer appropriate that the reference
implementation of flat_set_persistent() (ie: blackfins's implementation) be
completely undocumented. IMO.
> --- a/include/asm-h8300/flat.h
> +++ b/include/asm-h8300/flat.h
> @@ -9,6 +9,7 @@
> #define flat_argvp_envp_on_stack() 1
> #define flat_old_ram_flag(flags) 1
> #define flat_reloc_valid(reloc, size) ((reloc) <= (size))
> +#define flat_set_persistent(relval, p) 0
ug. those macros are crap. who did that. They will generate compiler
warnings and runtime failures in a whole host of well-known scenarios.
My kingdom to the person who invents a keyboard which delivers 12 kV when
it detects the sequence # d e f i n e. There is no reason why these
"functions" need to be implemented as crappy #defines and converting them
to C will fix bug, warnings and will clean stuff up.
Sigh.
next prev parent reply other threads:[~2007-09-28 23:08 UTC|newest]
Thread overview: 23+ 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
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 ` Andrew Morton [this message]
2007-09-28 23:48 ` [PATCH] binfmt_flat: minimum support for the Blackfin relocations Bernd Schmidt
-- strict thread matches above, loose matches on Subject: below --
2007-05-29 6:24 Bryan Wu
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=20070928160826.1483b9ba.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=bernd.schmidt@analog.com \
--cc=bryan.wu@analog.com \
--cc=davidm@snapgear.com \
--cc=gerg@snapgear.com \
--cc=linux-kernel@vger.kernel.org \
--cc=uclinux-dist-devel@blackfin.uclinux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox