From: Bernd Schmidt <bernds_cb1@t-online.de>
To: Paul Mundt <lethal@linux-sh.org>,
Bernd Schmidt <bernds_cb1@t-online.de>,
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.bader@necel.com,
linux-m32r@ml.linux-m32r.org
Subject: Re: [PATCH] binfmt_flat: minimum support for theBlackfin relocations
Date: Thu, 20 Sep 2007 16:56:20 +0200 [thread overview]
Message-ID: <46F28A14.6050501@t-online.de> (raw)
In-Reply-To: <20070920142543.GA3268@linux-sh.org>
Paul Mundt wrote:
> This is making API changes where it's convenient for your platform to use
> this value, and there's no reason to change the API here at all.
Your proposed addition of flat_validate_relval is an API change, and
very similar in nature to what I've done.
A local variable here is the most natural way to store this information.
What do you suggest we use, a global? A member in the task struct?
> Why should all architectures have to change their APIs (not just adding
> new things mind you, also changing existing definitions) to accomodate
> something that can trivially be kept in the blackfin code?
I don't see how there's a burden given that we've provided patches, and
most maintainers have already said their fine with it. It seems to me
that it's a natural and common thing for many architectures to be
updated when new things are added to core code.
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 14:57 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
2007-09-20 14:25 ` Paul Mundt
2007-09-20 14:56 ` Bernd Schmidt [this message]
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=46F28A14.6050501@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.bader@necel.com \
--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.