From: Bernd Schmidt <bernds_cb1@t-online.de>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: bryan.wu@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: Sat, 29 Sep 2007 01:48:31 +0200 [thread overview]
Message-ID: <46FD92CF.70708@t-online.de> (raw)
In-Reply-To: <20070928160826.1483b9ba.akpm@linux-foundation.org>
Andrew Morton wrote:
>> 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.
See below.
>> + 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?
The latter. We need to be able to use more data than we can fit into a
single reloc, so we store a value with one reloc and reuse it with the
next. There'd be no point in having this function otherwise since you
could perform whatever needs to be done in flat_get_relocate_addr.
This seemed fairly obvious at the time... when you're familiar with the
flat format, the loop isn't all that hard to understand. I'll add
comments in the next version.
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-28 23:49 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 ` [PATCH] binfmt_flat: minimum support for the Blackfin relocations Andrew Morton
2007-09-28 23:48 ` Bernd Schmidt [this message]
-- 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=46FD92CF.70708@t-online.de \
--to=bernds_cb1@t-online.de \
--cc=akpm@linux-foundation.org \
--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 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.